Closed Bug 8745 Opened 21 years ago Closed 21 years ago

[STARTUP PERF] [PP]libreg too slow on mac

Categories

(Core :: XPCOM, defect, P3, critical)

PowerPC
Mac System 8.5
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dp, Assigned: dveditz)

References

Details

(Whiteboard: [Perf])

Subject:
        Autoregistration on the Mac Profile
   Date:
        Tue, 22 Jun 1999 20:49:00 -0700
   From:
        davidm@netscape.com (David Matiskella)
    To:
        dp@netscape.com




I did a profile of the mac during autoregistration ( I bracked the calls to
NS_SetupRegistry_1)  last week and here
are the top time wasters.

Function Name     Count     Only %     +Children %
nr_UnlockRange     3712       39.9         39.9
nr_ReadFile         242596      29.6         31.0
nr_ReadDesc         121145       8.6         24.9
nsDll::Load()             130        8.4          8.4
nr_FindAtLevel         3731      2.1         43.6
nr_WriteFile             9888      1.9           1.9
nr_ReadLong         859445      1.7           1.7
nr_ReadName         117428     1.2          15.4
nsDll::nsDll(const char*) 438   1.0            1.1
memset                     251202   1.0            1.4
nsDll::Unload()                 43   0.6            0.6
nr_ReadShort             249714   0.5            0.5
__fill_mem                 251202  0.5             0.5

nr_UnlockRange time is spent in calling XP_FileFlush(). I am not sure what this
routine is trying to accomplish as
the LockArray function isn't implemented. If you just comment it out our loads
go about 2x as fast and everything
still works. Obviously doing over 200000 file reads is always going to be slow
on any non-memory mapped file. On
the mac it is particularly painful as you can end up switching between 68k
emulation mode and normal PPC code. We
really need to either put in a cache or just suck the whole file into memory.
Those are the 2 big areas of
improvement.  One other minor thing would be to use better routines for
converting between little endian and big
endian. There are macros which do a much better job of byte swapping ( only 2
memory access rather than the 5 of
the current routines) and by using either a macro or a inline function we should
get smaller and faster code since the
function call over head is more than the couple of instructions needed to swap
the bytes.
    Startup when the registry already exists is bottlenecked by  the nr_ReadFile
which takes ~65% of the time.
--
David Matiskella
XPApps
Blocks: 6361
Whiteboard: [Perf]
Blocks: 7251
Blocks: 5085
Status: NEW → ASSIGNED
UnlockRange used to be a no-op, a placeholder for file-locking. Earlier someone
(mcmullen?) declared that PR_SYNC mode didn't work on the mac and added the
explicit call (XP_FileFlush is #defined to PR_Sync() on the Mac, (void)1
elsewhere).

I'd be happy to remove it if you guys think it works OK.

I was holding off on caching the file because we had not yet decided whether we
were going to support multi-process use (important because of embedded Gecko).
If you're sure we're not going to revisit that decision I'll go ahead an
rewrite the code.

Oh, and those endian-swapping macros would be nice -- could someone send them
to me?
OS: Mac System 8.0 → Mac System 8.5
I would assume that there would be potential multiprocessor problems with
removing the XP_FileFlush is the sync mode doesn't work. If the only time the
registry is a performance bottleneck is during startup ( should profile to make
sure that this statement is true), couldn't we just lock the file exclusive use
during startup, suck into ram, do  the autoregistration,  dump the file out, and
then unlock lock the file.  I assume the componet registry will never get that
big ( it is currently only ~120k).
Summary: [STARTUP PERF] libreg too slow on mac → [STARTUP PERF] [PP]libreg too slow on mac
Target Milestone: M8
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
I removed the PR_Sync().
No longer blocks: 7251
Component: XPCOM Registry → XPCOM
QA Contact: dp → xpcom
You need to log in before you can comment on or make changes to this bug.