Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Sat, 29 Mar 2025 18:11:57 +0000
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <vs9d5c$1u88l$1@dont-email.me>
References: <vrd77d$3nvtf$2@dont-email.me> <vs25oi$2pqb$1@paganini.bofh.team>
 <QadFP.1351322$zz8b.870017@fx09.iad> <86r02iicl3.fsf@linuxsc.com>
 <JUzFP.529511$f81.413611@fx48.iad> <vs6jeh$31p79$3@dont-email.me>
 <dQDFP.256596$D_V4.171478@fx39.iad> <vs7788$3ml6o$1@dont-email.me>
 <87pli0wztv.fsf@nosuchdomain.example.com> <vs78vb$3o6s2$1@dont-email.me>
 <87ldsoww41.fsf@nosuchdomain.example.com> <vs7f33$3u1sk$1@dont-email.me>
 <vs8phl$1adfu$1@dont-email.me> <KhVFP.256599$D_V4.219803@fx39.iad>
 <w0WFP.1218505$OrR5.931702@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 29 Mar 2025 19:11:56 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0456d283b45811694d58326c90c160a7";
	logging-data="2040085"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19+Z1A5TvLJ9sICcBOmq4Yo"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:csneMywbPFbcKGRCdBSEugMS1ok=
In-Reply-To: <w0WFP.1218505$OrR5.931702@fx18.iad>
Content-Language: en-GB
Bytes: 4221

On 29/03/2025 17:23, Scott Lurndal wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 29/03/2025 01:32, bart wrote:
>>
>> <snip>
>>>
>>> So one of Scott's compiles takes 13 minutes.  "make -j" won't speed that
>>> up.  But it will mean that any other compilations can be done in
>>> parallel.  Maybe he has 600 other files that each take 30 seconds to
>>> compile.  With "make -j", the build takes the 13 minutes it has to for
>>> the one awkward file - all the rest are compiled while that is going on.
>>>   With non-parallel "make", it would take 5 hours (if I've done my sums
>>> correctly).
>>>
>>> Thus "make -j" is a really good idea, even if you have a particularly
>>> long-running task (compilation or anything else).
>>
>> Indeed there are several hundred source files.   The one under
>> discussion in this thread happens to be the 'long pole' that
>> dominates the overall build time.
> 
> So this discussion prompted me to manually break up that
> automatically generated large function into seven smaller functions.
> 
> The compile time with -O3 dropped by a factor of almost
> seven: 2 minutes 30 seconds.

Was the final binary still usable? If so then that's a result of sorts; 
you just need to tweak the automatic generation to do the same.

 >
 > Bart needs to argue about something.  Anything.

What makes you think I was arguing? I was just trying to understand how 
the compilation time was spent.

You however seem just to want to have a personal go at me, constantly.

(Would you have been included to do that experiment if I hadn't said 
anything about it.)

 > It is a single source file, compiled with a single instance
 > of g++.   That -j was provided to make is irrelevent.

Yet here you say something different:

 > Indeed there are several hundred source files.   The one under
 > discussion in this thread happens to be the 'long pole' that
 > dominates the overall build time.

So your presentation of it was confusing.

 > And this actually is a degenerate example of what happens when
 > one tries to include an entire program in a single source file,
 > something that bart seems to rather senseless continue to
 > advocate.

I'm not advocating it. It just what I happen to use for /generated/ 
source files, and what some people use for tidily packaging the sources 
for their programs or libraries for distribution.

For this purpose, it is (1) usually a one-off build, as all sources have 
to be processed anyway; (2) usually there are no 200Kloc functions; (3) 
you get the side benefit of whole-program compilation.

So there it makes sense.