[cfe-dev] Patch for IdentifierResolver

Argiris Kirtzidis akyrtzi at gmail.com
Wed Apr 9 21:59:38 PDT 2008


Chris Lattner wrote:
> Some thoughts:
>
> +  /// IdDeclInfoMap - Associates IdDeclInfos with Identifiers.
> +  class IdDeclInfoMap {
> +    std::list<IdDeclInfo*> IDIArrPtrs;
>
>
> std::list<pointer> is very inefficient, maybe llvm::ilist would work?  
> This puts the prev/next pointers in the IdDeclInfo object itself.  
> This can be a follow-on patch of course.
> http://llvm.org/docs/ProgrammersManual.html#dss_ilist

I didn't make it clear; "std::list<IdDeclInfo*> IDIArrPtrs;" doesn't 
contain all the allocated IdDeclInfos, just pointers to arrays of 
IdDeclInfos that serve as a kind of 'pools'
to avoid allocating each individual IdDeclInfo on the heap. With array 
size of 512 and needing only 1092 IdDeclInfos for carbon.h, you only get 
3 pools (just 3 elements to store in
IDIArrPtrs), thus the std::list doesn't make much of an impact on 
efficiency.

>
> +    static const unsigned int ARRAY_SIZE = 512;
> +    IdDeclInfo OrigArr[ARRAY_SIZE];
>
> This is sort of gross: 512 is a magic number, where did you get it?  
> Is this really needed? Maybe the ilist is enough?  The bad part about 
> this is that it adds a couple kilobytes into the middle of the sema 
> object, which seems suboptimal.

512 serves the same purpose as 32 in

 typedef llvm::SmallPtrSet<Action::DeclTy*, 32> DeclSetTy;

of Scope class, it only affects memory allocated.

OrigArr is supposed to be the initial pool of IdDeclInfos. Shall I 
allocate it to the heap instead ?
As it is now, pools of ARRAY_SIZE size are allocated on a need to have 
basis (to map identifiers to IdDeclInfos). Another idea would be to 
start from a small initial size and double the size of
the next pool when the initial pool is filled, or expand it by 1.5 etc.


-Argiris



More information about the cfe-dev mailing list