On Oct 5, 2012, at 3:19 PM, Diego Novillo <dnovi...@google.com> wrote: > On Fri, Oct 5, 2012 at 6:08 PM, Lawrence Crowl <cr...@googlers.com> wrote: > >>> For many people the time to compile (almost) empty file is very >>> important, we are already bad about that right now, initializing >>> too much stuff dynamically is going to make it worse. >> >> So far, we are looking at dynamic initializations that would >> take about 10 cycles. Even on a slow processor, a thousand >> initializations would take a microsecond. Our time reports don't >> even report anything less than 5 milliseconds. >> >> Is there any reason to believe that this anticipated static >> initialization overhead is not pretty low relative to other overhead? >> I'm thinking here of the fact that to even start, the driver launches >> cc1[plus] which has to parse all the options created by the driver. > > I agree. I don't think this will be a real problem.
I hope you're right. Experience tells me that the usual high cost a single dynamic initialization is 30,000,000 cycles, about 100 of them cost 1 second. Costs of the low side, are completely irrelevant. I think the 10 cycle cost is not the high side, but the irrelevant low side number. If one wanted to understand the actual cost one can take a snap of the cycle counter before the dynamic inits happen (or near the front of them) and take a snap of it after they run, and examine the difference… A difference of 0, means, though one might conceive of them as dynamic inits, they are not. And the other number is what it is. A global cycle counter that free runs as a time of day counter can see the page faults, tlb misses and all the other hair, while per process cpu used counter is less useful.
