RE: [cdt-dev] Symbol translation concerns

[Thomas Fletcher <ThomasF@xxxxxxx>]

OK ... after a few months hiatus from this topic, I've pushed this
change through along with some modifications based on conversations
with Dave I.

- The SymbolSort class is being deprecated alltogether. I removed it,
but apparently that was a bit too radical so I'll put it back in but
deprecate its use.

- The Elf.Symbol arrays returned from the Elf classes are not documented
as being name sorted on return, so we aren't going to do that (this is
the only CDT client of the SymbolSort class).

Thanks,
 Thomas   

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Fletcher
> Sent: January 16, 2006 3:13 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Symbol translation concerns
> 
> OK, doesn't seem like anyone has an opinion, I'll put the 
> changes in and we'll see what happens.
> 
> Thanks,
>  Thomas 
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Fletcher
> > Sent: January 9, 2006 1:45 PM
> > To: CDT General developers list.
> > Subject: [cdt-dev] Symbol translation concerns
> > 
> > Hey all,
> > 
> >   I'm currently doing some work in the area of the symbol 
> translator.  
> > I'm particularly looking at improving a few performance bottlenecks 
> > that are easily attacked and then looking at ways to get rid of the 
> > larger issues (ie can we have a native parser for the 
> symbols instead 
> > of addr2line/cppfilt combinations).
> > 
> >   I have a couple of questions to see if I can tickle the larger 
> > community memory since I'd rather not break things that are 
> working.  
> > I don't think that this will, but I'm probing anyway since 
> there is a 
> > collective memory here.  The first target is to make a few 
> changes to 
> > the Elf/ElfHelper classes:
> > 
> > 1- The SymbolSortCompare class converts all of its symbols to 
> > lowercase (via
> > .toLowerCase())
> > and then performs a comparison.  On large symbol files 
> (anything over 
> > a couple of megs) this can create a flurry of object 
> creations.  I'm 
> > going to change this code to not convert the strings to 
> lower case but 
> > instead (initially) use compareToIgnoreCase().  The 
> performance gains 
> > observed are not insignificant:
> > 
> > Original (time to sort the symbol array used by the 
> ElfHelper class):
> > - Sorting 53580 symbols took 6203ms
> > Modified (traded toLowerCase for compareToIgnoreCase)
> > - Sorting 53580 symbols took 828ms
> > 
> > 2- The second "thing" that the SymbolSortCompare class is 
> to strip out 
> > any leading underscores.  I'm not sure what the rationale 
> is for doing 
> > this but it seems wrong to me to be arbitrary ripping out leading 
> > underscores (__start != _start != start).
> > 
> > Looking at the bigger picture, the general use of the 
> symbols does not 
> > seem to require them being sorted at all, and since the 
> behaviour is 
> > not documented I'm tempted to toss the lot .. but baby steps first.
> > 
> > Proposal:
> > - I'm going to switch the sorting to continue to be case 
> in-sensitive 
> > but using the compareToIgnoreCase
> > - I'm going to remove the leading underscore "filtering" of the 
> > sorter.
> > This may
> > have some relation to PR 87698, I'm still looking into that.
> > 
> > Thanks,
> >  Thomas
> >  
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>