Caching in druntime TypeInfo classes

[deadalnix via Digitalmars-d]

On Tuesday, 30 June 2015 at 21:17:13 UTC, H. S. Teoh wrote:
> While investigating:
>
> 	 https://issues.dlang.org/show_bug.cgi?id=4244
>
> I found that the druntime function for computing the hash of 
> static arrays (this also applies to dynamic arrays, btw) is 
> horrendously slow: about 8-9 times slower than the equivalent 
> operation on a POD struct of the same size.
>
> The problem is caused by the call to hasCustomToHash() inside 
> getArrayHash() in object.d, which in turn calls getElement(), 
> which walks the typeinfo tree to find the TypeInfo for the 
> first non-array / typedef type info definition, in order to 
> determine if array elements have a custom toHash method. This 
> walk is done *every single time* the array is hashed, even 
> though the return value never changes for each array type.
>
> So I tried to modify getArrayHash() to cache this information 
> in the TypeInfo, but ran into some roadblocks: since TypeInfo's 
> are supposed to be const, this operation is illegal. Unless I 
> cast away const, but that's a rather dirty hack. The other 
> problem is that the compiler hardcodes the sizes of each 
> TypeInfo instance, so it will refuse to compile object.d anyway 
> if the TypeInfo is expanded to have an extra field for caching 
> the result of hasCustomTohash(). But since we have to modify 
> the compiler now, my reaction was, why not have the compiler 
> compute this value itself? Since the compiler already has all 
> the information needed to compute this value. We don't have to 
> wait till runtime. The only drawback is adding more complexity 
> to the compiler, making it hard for other efforts like SDC to 
> implement D.
>
> What do you guys think? Should hasCustomToHash() be cached 
> somehow in object.o? Or is caching a poor solution, and we 
> should do something else?
>
>
> T

This should not use typeinfo at all IMO.

We have template to do exactly that.