[Bug default/19355] [PERF] Libabigail slow on the r300_dri.so binary

["dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19355

--- Comment #2 from dodji at redhat dot com ---
The series of 5 patches which landed in the master branch of the libabigail
code repository, with the latest one being
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=5a8c000a8714d588346aaf290d7ccde9a1a46174
should somewhat address a number of the issues raised in this problem report.

abidw --abidiff r300_dri.so, on a dwz'ed version of r300_dri.so now takes 12
minutes.  This more than 4x speed increase.  And it doesn't abort anymore.

So now, abidw --abidiff on a compressed (with dwz) r300_dri.so is "only" 4
minutes slower compared to abidw --abidiff on a non compressed one.

The reason for such a difference lies in how we compute the logical parent of a
DIE that has been imported using DW_TAG_imported_unit.

Keep in mind that a given DIE (named D) can be imported several times at
several places of the translation unit.  To get the logical parent of D, we
need to find out where D has been imported.  Looking for that import point
takes a certain (non-constant) amount of walking the translation unit.

It's that walking time that explains the 4 minutes difference on the (huge)
r300_dri.so debug info.

To reduce that time further, an option would be to build the data structure
representing DIEs in such a way that getting the logical parent would be an
operation that is bounded in time, if not constant.  In the short term, that
would imply that libabigail builds its own representation of DIEs, rather than
relying on the DIE representation provided by elfutils.

Note that the time taken on by abidw --abidiff on non-compressed binaries
hasn't changed so far.

-- 
You are receiving this mail because:
You are on the CC list for the bug.