A few measurements of stat()'s speed

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Mar 26 20:09:52 UTC 2019


On 3/26/19 2:36 PM, H. S. Teoh wrote:
> Does caching the contents of import directories cause significant
> overhead?  If not, why not just cache it anyway, regardless of whether
> the import happens across network mounts.

Because testing takes 10 minutes and implementation takes one day or 
more. We want to make sure there's impact.

> On a slightly different note, why are we paying so much attention to
> import speeds anyway?

You destroy your own opening point: work should be put where there's 
potential for impact, not "regardless".

> We can optimize import speeds to hell and back
> again until they cost practically zero time, yet the act of actually
> *using*  one of those imports -- ostensibly the reason you'd want to
> import anything in the first place -- immediately adds a huge amount of
> overhead that by far overshadows those niggly microseconds we pinched.
> Ergo:
> 
> 	import std.regex;
> 	void main() {
> 		version(withRegex)
> 			auto re = regex("a");
> 	}
> 
> This takes about 0.5 seconds to compile without -version=withRegex on my
> machine. With -version=withRegex, it takes about *4.5 seconds* to
> compile.  We have a 4 second bottleneck here and yet we're trying to
> shave off microseconds elsewhere.  Why does instantiating a
> single-character regex add FOUR SECONDS to compilation time?  I think
> *that*  is the question we should be answering.

There's a matter of difficulty. I don't have a good attack on 
dramatically improving regexen. If you do, it would be of course a high 
impact project. There's also a matter of paying for what you don't use. 
Unused imports are, well, unused. Used imports should be paid for in 
proportion. Agreed, 4.5 seconds is not quite proportionate.


More information about the Digitalmars-d mailing list