From: bc@freeuk.com
On 31/10/2025 17:18, Scott Lurndal wrote:
> bart writes:
>> On 31/10/2025 13:57, Scott Lurndal wrote:
>>> bart writes:
>>>> On 30/10/2025 16:22, Scott Lurndal wrote:
>>>>> bart writes:
>>>
>>>>>>
>>>>>> What is the total size of the produced binaries?
>>>>>
>>>>> There are 181 shared objects (DLL in windows speak) and
>>>>> six binaries produced by the build. The binaries are all quite small
since
>>>>> they dynamically link at runtime with the necessary
>>>>> shared objects, the set of which can vary from run-to-run.
>>>>>
>>>>> The largest shared object is 7.5MB.
>>>>>
>>>>> text data bss dec hex filename
>>>>> 6902921 109640 1861744 8874305 876941 lib/libXXX.so
>>>>
>>>> Well, I've done a couple of small tests.
>>>
>>> Pointlessly.
>>>
>>>>
>>>> The first was in generating 200 'small' DLLs - duplicates of the same
>>>> library. This took 6 seconds to produce 200 libraries of 50KB each (10MB
>>>> total). Each library is 5KB as it includes my language's standard libs.
>>>
>>> The shared object 'text' size ranges from 500KB to 14MB.
>>
>> Well, I asked for some figures, and they were lacking. And here, the
>> 14MB figure contradicts the 7.5MB you mentioned above as the largest object.
>
> The 7.5MB was the shared object containing the main code. 14MB
> was one outlier that I hadn't expected to be so large a text region (am
> actually looking into that now, I suspect the gcc optimizer doesn't handle
> a particular bit of generated data structure initialization sequence very
well).
>
> $ size lib/*.so | cut -f 1
>
> text
> 367395
> 8053916
>
> A couple are third-party libraries distributed
> in binary form (e.g. the ones with 30+Mbytes of text).
In sorted form:
1 4,997 bytes
2 6,539
3 6,552
...
178 30,062,440
179 33,698,635
180 35,760,664
181 36,084,944
About 330MB, or 260MB if disregarding the two biggest.
That's quite substantial, but still, going with my test which built
4.5MB in one second, 60 such builds would take a minute, totalling a
260MB. Say add a bit more if split into 180 separate builds.
And that is if done one at a time.
So I still contend that the basic translation can still be done in a
reasonable time, /if/ you really had to rebuild everything.
(When I rebuild everything, it's because a module is part of one
executable, so that whole binary must be rebuilt.)
>> If your tests have a effective throughput far below that, then either
>> you have very slow compilers, or are doing a mountain of work unrelated
>> to compiling, or the orchestration of the whole process is poor, or some
>> combination.
>
> Or your tools are not capable of building a project of this size
> and complexity. If they were, they'd likely take even _more_ time
> to run.
Perhaps not, but so what? I've always developed tools according to the
tasks and circumstances that were relevant to me.
And usually, for building my own software.
They just happen to also be a great deal zippier in operation when
compared with other tools for building the same codebases.
I'm pretty certain they have inefficiences that someone could address if
they wanted to, or could choose to find streamlined paths if a fast
turnaround was desirable.
That's why I said it should be somebody's job to do that, in the same
way that I considered it part of my job to ensure my development process
wasn't slow enough to slow me down. If I'm twiddling my thumbs, then
something's wrong!
>>
>> (You mentioned there are nearly 400 developers involved? It sounds like
>> a management problem.
>
> I said nothing about the number of developers (perhaps you were looking
> at the output of the 'sloccount' command?)
Yes. (I'm not sure what that was about.)
> Between 2 and 8 developers have worked on this project
> at any one time over the last 15 years.
You might want to clear out some cruft then.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
