Closed Bug 8745 Opened 21 years ago Closed 21 years ago
[STARTUP PERF] [PP]libreg too slow on mac
Subject: Autoregistration on the Mac Profile Date: Tue, 22 Jun 1999 20:49:00 -0700 From: email@example.com (David Matiskella) To: firstname.lastname@example.org 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
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?
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
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
I removed the PR_Sync().
You need to log in before you can comment on or make changes to this bug.