Sujet : Re: Suggested method for returning a string from a C program?
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 29. Mar 2025, 19:11:57
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vs9d5c$1u88l$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Mozilla Thunderbird
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.