187185 - Performance regression in pr_LoadLibraryByPathname [Mach-O]

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Conrad Carlen (not reading bugmail)]

This happened from the fix for bug 131036. I measured Ts time on my opt trunk
build pulled today.

without bug 131036 fix: 3604
with: 4254

That's pretty significant. The code tries GetDiskFragment() and then
getLibraryBundle() before NSCreateObjectFileImageFromFile(). The latter is the
most common case, certainly at startup, and it's being executed last after the
others which are expensive.

Comment 1

[Conrad Carlen (not reading bugmail)]

Whoops - make that bug 131306.

Comment 2

[Wan-Teh Chang]

Thanks for writing this bug, Conrad.  This can be fixed
by reordering the code in nsprpub/pr/src/linking/prlink.c.

Between GetDiskFragment() and getLibraryBundle(), which
one should we try first?

Comment 3

[Simon Fraser [no longer active]]

Can we just bite the bullet and clean up all the #idfefs in that routine now?

Comment 4

[Conrad Carlen (not reading bugmail)]

I'm going to take care of this with bug 186599.

I plan on breaking the different methods used inside pr_LoadLibraryByPathname
out into subroutines and using an array of function pointers which can be
reordered. That should clean up some of the #ifdef mess.

Comment 5

[Wan-Teh Chang]

Fixed by the patch in bug bug 186599.

Comment 6

[Wan-Teh Chang]

Who can verify the Ts time is back to what it was
before bug 131036 fix?

Comment 7

[Wan-Teh Chang]

Sorry, that should be bug 131306.