http://bugs.winehq.org/show_bug.cgi?id=836
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #8 from Eric Pouech eric.pouech@orange.fr 2008-02-06 14:48:19 --- not done yet anyway, it would require a rather in depth rewrite of the whole dbghelp DLL. basically, what we currently do is: - parse the symbols and types of a given module - there's a specific backend for each known debug format (pdb, stabs, dwarf...) - this is stored as an ad hoc format inside dbghelp (hence the backend transform the given debug format to this intermediate format)
we do load info about a module the first time we need info about a module (looking a symbol by address, or by name, or...)
even if we'd parse correctly the hash tables out of pdb files, it still wouldn't help because of previous point. and of course we store in the intermediate format the symbols' name in a hash table, so once the module's info is loaded, performance is acceptable
what should really be fixed is the granularity of the symbols' storage dbghelp for now has two states for a module: 1/no info, 2/ all debug info loaded that's where we need finer grain, but we need also to abstract the different debug format parsers according to this finer grain, which won't be trivial
anyway, some intermediate work has been done (12/18 months ago iirc) to speed up the memory management of the intermediate format management. there could be some easier speed improvement here
A+