Pay as you go is really going to make a difference

Steven Schveighoffer schveiguy at
Fri Jan 24 19:54:01 UTC 2020

On 1/24/20 1:24 PM, H. S. Teoh wrote:
> On Fri, Jan 24, 2020 at 08:06:33AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 1/24/20 4:52 AM, Johan Engelen wrote:
> [...]
>>> Indeed. Also to figure out why LDC's binary calls 31 more than DMD's
>>> binary.
> [...]
>> Most likely it's the runtime startup. Obviously sbrk quite a bit, but
>> any runtime initialization (thread startup, mutex initialization, etc)
>> are all going to go in there. Think of what the GC has to do!
> [...]
> It makes me wonder how much we can make all this startup stuff
> pay-as-you-go.  I mean, IIRC, isn't the GC lazily initialized now? I
> vaguely remember some PR along that direction. Or was it the pool
> allocations?

Yes, it is lazily initialized. It's kind of a cool mechanism too -- the 
"default" GC is a class that when used in a way where a "real" GC is 
needed (e.g. allocate some memory), figures out which one to create, 
creates it, and then replaces itself as the global handler with that new 

But the GC is going to be initialized in a writeln call I think.

There's a few other things that are going to cause a lot of system calls 
too -- the static constructors and the cycle detection. At least the 
cycle detection we could rid ourselves of if we could make a 
post-compile step that runs the cycle detection algorithm and sets up 
the final ordering in the binary.

> I suppose thread startup would be hard to elide, unless there was a way
> to initialize the thread stuff only on demand. Ditto for mutex inits.
> But it might not be worth the effort for such minimal benefits in such a
> marginal test case.

I'm not sure why we need to exactly minimize the system calls, we should 
just be able to explain them. 150 calls isn't horrific, and trying to 
reduce an "artificial" metric like that really shouldn't be the goal. I 
know this is exactly what the author is complaining about, but there is 
a world of difference between a 50MB web site that can't scroll and 150 
system calls to do runtime startup + print hello world.

However, there could easily be an obvious candidate for removal if 
something looks like it's being called way too often. So explanation is 
still a good goal.


More information about the Digitalmars-d mailing list