DMD internal: appendToModuleMember performance

[David Nadlinger via Digitalmars-d]

On Friday, 15 April 2016 at 18:33:44 UTC, Johan Engelen wrote:
> Hi all,
>   When building a unittest case in Weka.io's codebase, I 
> measure that appendToModuleMember takes about 10% of the total 
> compile time, and about 25% of total semantic analysis time. 
> "appendToModuleMember" is the only function that pops up in 
> profiling with such a large time fraction spent in it.

Yep, see also: https://issues.dlang.org/show_bug.cgi?id=15323. 
When I tried to get rid of the ordered array, I ran into several 
interesting issues, but I don't remember many details.

> I'm thinking about removing the old array all-together.
> My question is: is it essential to keep an ordered list? (I see 
> a `.shift(...)` call on the array, to put something in first 
> position. If so, could that be solved by having *two* trees, 
> where "in-order" iteration first iterates over the first one 
> and then the second. The "high priority" symbols can then be 
> put in the first tree, normal ones in the second tree (if that 
> is how order matters...).

Another "quick fix" if we have to keep the order would be to add 
a Bloom filter/… on the side to eliminate most array searches.

  — David