Hi,
dwfl_module_addrsym is a bit slow because it wants to return global symbols in preference to local symbols, but first looks at all the local symbols. To speed this up I wrote the following patches, which introduces dwfl_module_symtab_global to get the first index of the global symbols in the symtab. And the uses this in dwfl_module_addrsym to search through the global symbols first, and only if no symbol was found, go through the local symbols afterwards.
This gives a nice speedup on readelf -w libstdc++.so.debug for example, from 35 seconds to 25 seconds, on my machine. The output is exactly the same.
Comments?
Thanks,
Mark
I'm not entirely sure about having this as a new public interface. It might make more sense to return the Elf_Scn of the symtab or something like that. My inclination is to start out by only using the information internally, and think about a public interface for it later when there is actual demand for that.
I think "symglobals" is an unnatural name for fields and variables for this. It looks like a count, and what it's the count of is the locals. So something like "nlocals" or "first_global" makes more sense to me.
Thanks, Roland
On Mon, Oct 31, 2011 at 11:03:42AM -0700, Roland McGrath wrote:
I'm not entirely sure about having this as a new public interface. It might make more sense to return the Elf_Scn of the symtab or something like that. My inclination is to start out by only using the information internally, and think about a public interface for it later when there is actual demand for that.
The patch started out with just that dwfl_module_symtab_global function, to make a more efficient version of dwfl_module_addrsym that searched the globals first. Then I realized I should just make dwfl_module_addrsym be more efficient itself.
I only wanted to expose the index where the globals started (if known) since that is all you need to use it together with dwfl_module_getsymtab and dwfl_module_getsym. The symbols don't actually have to come from an actual Elf_Scn, they could come from the dynamic symbol table via phdrs.
I removed the public interface for now and just access the field directly in dwfl_module_addrsym. Any preference on a public interface?
I think "symglobals" is an unnatural name for fields and variables for this. It looks like a count, and what it's the count of is the locals. So something like "nlocals" or "first_global" makes more sense to me.
first_global does sound better. I changed it in the attached patch. OK, to commit this version for now, while we discuss whether or not and how the public interface should look?
Thanks,
Mark
I only wanted to expose the index where the globals started (if known) since that is all you need to use it together with dwfl_module_getsymtab and dwfl_module_getsym. The symbols don't actually have to come from an actual Elf_Scn, they could come from the dynamic symbol table via phdrs.
Ah, good point.
I removed the public interface for now and just access the field directly in dwfl_module_addrsym. Any preference on a public interface?
I prefer to wait until there is a concrete prospective user.
first_global does sound better. I changed it in the attached patch. OK, to commit this version for now, while we discuss whether or not and how the public interface should look?
Rather than the goto, move the matching loop into a nested function that takes the loop bounds as arguments. Then just call that twice.
Thanks, Roland
On Mon, 2011-10-31 at 15:30 -0700, Roland McGrath wrote:
Rather than the goto, move the matching loop into a nested function that takes the loop bounds as arguments. Then just call that twice.
That does look nicer than the trusty old goto construct. Pushed with that change (diff -b attached, actual diff was lots of indentation changes).
Thanks,
Mark
elfutils-devel@lists.fedorahosted.org