Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: else ladders practice Date: Thu, 28 Nov 2024 15:25:48 +0000 Organization: A noiseless patient Spider Lines: 70 Message-ID: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> <86y117qhc8.fsf@linuxsc.com> <86cyiiqit8.fsf@linuxsc.com> <86mshkos1a.fsf@linuxsc.com> <20241128143715.00003565@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 28 Nov 2024 16:25:47 +0100 (CET) Injection-Info: dont-email.me; posting-host="033a1fb1a70fe4f5596322438ef79f57"; logging-data="601183"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+/b4rnInbcDp5ZokEuObbi" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:rxXe1UH2YqPWfSEtg7KvOFMYGNA= In-Reply-To: <20241128143715.00003565@yahoo.com> Content-Language: en-GB Bytes: 4359 On 28/11/2024 12:37, Michael S wrote: > On Wed, 27 Nov 2024 21:18:09 -0800 > Tim Rentsch 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.