Slow analyzing large elf files (parallelize?)

[infn-ke]

I find that puncover is really slow analyzing my elf files, significantly slower than e.g. bloaty. Is there any way to speed up the analysis? E.g. can it run the objdump in parallel?

[paulwuertz]

Profiling a known slow analysis of the prusa 3d printer firmware cProfile and looking at it in snakeviz a single culprit - the call to nm -Sl reveals itself 1440 out of 1470 seconds of runntime just the call to nm -Sl :)

You can easily see this by running nm -Sl YOURELFFILE.elf, if you drop the -l option it finishes in an instant, so the -l option adds 99% of the runtime there for some reason... Getting the symbols+size a different way, like the mapfile as suggested in #41 could be much faster. Or maybe by using pyelf... But I do not see why adding the line-number option in nm makes it so slow...

Will try to play around with some ideas to speed that up :)

[paulwuertz]

In the binutils it also states at the nm source, that the --line-numbers option will be slow:

/* We need to get the canonical symbols in order to call
bfd_find_nearest_line. This is inefficient, but, then, you
don't have to use --line-numbers. */

As far as I understand it, after the symbols are extracted it searches all the debug symbols for each symbol. Wrapping my head around the macros there seems not so straight forward. Building a map and looking it up may speed nm itself up.