Liste des Groupes | Revenir à cl c |
On 03/12/2024 14:34, David Brown wrote:By "a typical build", I mean I make some modifications or changes to some code, then build the project to check for any static warnings and have the binaries ready to download to the target board for testing. Nothing is being "missed out".On 02/12/2024 22:53, Bart wrote:For the project-specific code, rather than libraries, SDK, etc.:
>
-----------------------------------------------------------------------
Language files blank comment code
-----------------------------------------------------------------------
C++ 39 2217 1020 11820
C/C++ Header 44 1078 798 2696
C 3 259 237 1152
-----------------------------------------------------------------------
SUM: 86 3554 2055 15668
------------------------------------------------------------------------
>Not that it really matters, but a typical build for my project takes about 1 to 3 seconds.I don't really know what they means, because I don't know is involved, and what is being missed out.
So, to get an idea of how long gcc really takes (or would take on my machine), I set up a comparable test. I took an 800-line C program, and duplicated it in 200 separate files f1.c to f200.c, for a total line count of 167Kloc.All you are showing is that you don't understand how to use compilers or how to build projects beyond little "hello world" tests.
gcc took 30 to 90 seconds to create an EXE using -O0 and -O2.
Under WSL, it took 18 to 54 seconds 'real time' (to .o files; it can't link due to Win32 imports).
Tiny C took 0.64 seconds.
My two C compilers were rubbish so I won't report those timings (the newer one only works a file at a time anyway so needs invoking 200 times).
However the equivalent test in my language, of 160 versions of a somewhat larger module, took 0.57 seconds (unoptimised compiler).
Anyway, the gcc timings give a different picture from your 1-3 seconds.
Les messages affichés proviennent d'usenet.