Liste des Groupes | Revenir à cl c |
On 26/05/2024 12:09, David Brown wrote:On 26/05/2024 00:58, Keith Thompson wrote:For a very large file, that could be a significant burden. (I
don't have any numbers on that.)
I do :
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
(That's from a proposal for #embed for C and C++. Generating the
numbers and parsing them is akin to using xxd.)
More useful links:
<https://thephd.dev/embed-the-details#results>
<https://thephd.dev/implementing-embed-c-and-c++>
(These are from someone who did a lot of the work for the
proposals, and prototype implementations, as far as I understand
it.)
Note that I can't say how much of a difference this will make in
real life. I don't know how often people need to include
multi-megabyte files in their code. It certainly is not at a level
where I would change any of my existing projects from external
generator scripts to using #embed, but I might use it in future
projects.
I've just done my own quick test (not in C, using embed in my
language):
[]byte clangexe = binclude("f:/llvm/bin/clang.exe")
proc main> fprintln "clang.exe is # bytes", clangexe.len
end
This embeds the Clang C compiler which is 119MB. It took 1.3 seconds
to compile (note my compiler is not optimised).
If I tried it using text: a 121M-line include file, with one number
per line, it took 144 seconds (I believe it used more RAM than was
available: each line will have occupied a 64-byte AST node, so nearly
8GB, on a machine with only 6GB available RAM, much of which was
occupied).
The figures at your link say it took 1 second for a 40MB test file,
on an Intel i7 with 24GB.
>
My compiler took just over 1.3 seconds (now annoyingly taking 1.4
seconds for a retest) for a file nearly 3 times bigger, on a much
more lowly machine (second cheapest PC in the shop), with 8GB.
So my implementation sounds faster. Of course, those 120M data bytes
haven't been optimised!
>
As for usage, this would be a tidy way of bundling a program like a C
compiler if your program required it, although there are a number of
alternatives in that case: the binary here doesn't need to exist in
the application's data space.
Les messages affichés proviennent d'usenet.