Re: else ladders practice

On 28/11/2024 12:37, Michael S wrote:

On Wed, 27 Nov 2024 21:18:09 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

   c:\cx>tm gcc sql.c            #250Kloc file
   TM:  7.38

>
Your example illustrates my point.  Even 250 thousand lines of
source takes only a few seconds to compile.  Only people nutty
enough to have single source files over 25,000 lines or so --
over 400 pages at 60 lines/page! -- are so obsessed about
compilation speed.

My impression was that Bart is talking about machine-generated code.
For machine generated code 250Kloc is not too much.

This file mostly comprises sqlite3.c which is a machine-generated amalgamation of some 100 actual C files.
You wouldn't normally do development with that version, but in my scenario, where I was trying to find out why the version built with my compiler was buggy, I might try adding debug info to it then building with a working compiler (eg. gcc) to compare with.
But, yes, when I used to do more transpilation to C, then the generated code would be a single C source file. That one could also require frequent recompiles as C, if there were bugs in the process.
Then the differences in compile-time of the C are clear; here, generating qc.c from the original sources took 0.09 seconds:
c:\qx>tm gcc qc.c            GCC -O0
TM: 2.28
c:\qx>tm tc qc               TCC from a script as it's messy
c:\qx>tcc qc.c c:\windows\system32\user32.dll -luser32 c:\windows\system32\kernel32.dll -fdollars-in-identifiers
TM: 0.23
c:\qx>tm cc qc               Using my C compiler
Compiling qc.c to qc.exe
TM: 0.11
c:\qx>tm mm qc               Compile original source to EXE
Compiling qc.m to qc.exe
TM: 0.09
c:\qx>tm gcc -O2 qc.c        GCC -O2
TM: 11.02
Usually tcc is faster than my product, but something about the generated C (maybe long, messy identifiers) is slowing it down. But it is still 10 times faster than gcc-O0.
The last timing is gcc generating optimised code; usually the only reason why gcc would be used. Then it takes 120 times longer to create the executable than my normal native build process.
Tim isn't asking the right questions (or any questions!). WHY does gcc take so long to generate indifferent code when the task can clearly be done at least a magnitude faster?
Whatever it is it's doing, why isn't there an option to skip that for a streamlined build? (Maybe you accidentally deleted the EXE and need to recreate it; it doesn't need the same analysis.)
I've several times suggested that gcc should have an -O-1 option that runs a secretly bundled version of Tiny C.