The cost of stack traces

Wed May 10 20:19:00 GMT 2006

Something I wanted to do in the DWARF reader I wrote (but never did, 
since the patch wasn't accepted) was to cache *approximate* 
information about where to look for debug info for an address. So 
you'd have a range of PC values that would map to regions in 
the .debug_line section where you would find the debug info you were 
looking for. That would probably help lookup times, at least in a 
long-running application, and the map wouldn't need to contain too 
much data.
The big slowdown, from what I can tell, is that you have to scan from 
the very beginning of the debug info to find the address, and that 
can be slow for huge libraries like libgcj. You could probably 
optimize the hell out of this, by scanning a library just once and 
building a good, approximate cache of where to look things up.
Shall I post my patch for this again? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060510/30d7693f/attachment.sig>