Closed Bug 48888 Opened 24 years ago Closed 22 years ago

optimize xpcom component registry

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: dougt, Assigned: dougt)

References

Details

(Keywords: perf, Whiteboard: [driver:blizzard][adt3 RTM][wgate])

Attachments

(1 file, 6 obsolete files)

patch 7
120.28 KB, patch
dp
: review+
waterson
: superreview+
Details | Diff | Splinter Review 
Currently we use libreg for our component registry.  libreg has a binary data
format which allows quick data access.  However, the way the component manager
loads its data is linear.  We need to use a datasource which is more inline with
the usage. 

we should replace libreg with a tab delimited file (or something similar).
Blocks: 46737, 47378
Assignee: warren → kandrot
Keywords: perf
Reassigning to kandrot. Note: I'm not convinced that the current registry scheme 
is a problem -- we need to measure it first.
Status: NEW → ASSIGNED
leger@netscape.com is no longer a valid email. reassigning qa contact to the
component's default.
QA Contact: leger → rayw
I will take a look into this.  I am not currently savvy on the issues involved,
so I will need to find out the pluses and minuses to doing this.
Target Milestone: --- → mozilla1.0
reassigning kandrot bugs.
Assignee: kandrot → dougt
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
Blocks: 98275
I think that we all agree that their is room for improvement here.  Currently I
see 3 disk hit to read in this file even with a 500k buffer!  Over to cathleen.
 Maybe we can get some data as to how much time to we spend reading in this
registry and how much is acceptible.
Assignee: dougt → cathleen
-> shaver

shaver, is this something you can help?
Assignee: cathleen → shaver
Yeah, I could.  Not soon, though.
Target Milestone: --- → mozilla0.9.7
shaver will you be able to get to this for 0.9.7  :-)
Keywords: mozilla0.9.9
Pretty Ironic!!  Just today, I am finishing up a patch which uses a flat file
instead of the component registry.  If you like, reassign.
reassigning.
Assignee: shaver → dougt
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Keywords: nsbeta1+
Inital data show ~ 1% speed improvement of main1().  
Overview of patch:

This is a large patch which replace the nsIRegistry backend store with a flat
file.  I have data that shows that this is a bit more than a 1% improvement in
startup time.

Details:

At startup of XPCOM, we will look for a registry file located within the
components directory named compreg.dat.  It will be read in and this data will
populate the component and category manager's hashtables.  

In addtion, information about component files that have been found during prior
AutoRegistrion will populate a new data structure within the component manager.
 This replaces the stat information in the xcdll and allows a uniform handling
of component file stat information.  To achieve this, a new interface has been
invented: nsIComponentLoaderManager.  Methods on this new interface allow for
storage and retrieve of component file information.  No longer does xcdll need
to cache file stat information.  It can use this new interface.  Similarly the
javascrip loader does the same.

I removed a bunch of code related to nsIRegistry handling.  

I added a function so that one can enumerator all of the categories.  I needed
this so that I could dump every category topic to disk. 


Registry File Format:

The format is a text file containing the following:

[HEADER]
version: x.x.x

[COMPONENTS]
name,file_size,last_modification_date,component_count

[CONTRACTIDS]
bcontract_it,cid

[CLASSIDS]
cid,contract_id,type,class_name,inproc_server

[CATEGORIES]
category,topic,data

There are arguements for having a text file just as well has making this a
binary file.  In either case, I went with what was easist for both debugging
and implementation.  

TODO's

- We need to make sure that the static component builds work.
- Need to test this on linux and mac.
- Maybe we should try to speed up the nsICategoryManager write. 
- testing testing testing.  I will be placing a opt build on ftp.mozilla.org
later today.
A few things.. 
1) I'm not clear here - are we going to journal? It would seem a shame to write
out this file every time, as it will get pretty big.
2) mork is already a small, fairly fast, no-dependency, journal-based database
that does smart atomization, has a compaction api, etc (which might benefit
things like classes registring with multiple ProgIDs, etc.) Have we looked at
that at all? It has been in use in mozilla for over 2 years, and we know it to
be corruption-free (at least in the last 2 years)
3) the nsPersistentProperties file format, shared with Java, is a pretty good
flat storage format. It doesn't have the basic hierarchy that you define, but
that could easily be created with simple semantics. We already have a bug on
speeding up .properties file access.. 
4) are we really sure its worth the risk/reward to completely change the file
format for a 1% startup improvement this close to mozilla 1.0? It just seems
like high risk/low reward, and not exactly a 1.0-ship-stopper :(

I think a new format could be really great, I just want to make sure we're doing
the right thing at this stage in the game.

A few things.. 
1) I'm not clear here - are we going to journal? It would seem a shame to write
out this file every time, as it will get pretty big.

>> What gave you this impression?  We do not write this file out everytime. 
Only when the hash is dirty do we.  The only time that the has is dirty is after
someone registers a new component.  

2) mork is already a small, fairly fast, no-dependency, journal-based database
that does smart atomization, has a compaction api, etc (which might benefit
things like classes registring with multiple ProgIDs, etc.) Have we looked at
that at all? It has been in use in mozilla for over 2 years, and we know it to
be corruption-free (at least in the last 2 years)

>> Have not looked at mork or any other database since we want prepopulation for
performance.  Based on this, reading in the hashes seamed like the simpliest and
safest thing to do.  

>> Assuming that prepopulation is where we want to go, my patch moves us in a
direction closer to backstore independence.  After my change, there is a pinch
point where all the hashes are read into memory and written back to disk.  

3) the nsPersistentProperties file format, shared with Java, is a pretty good
flat storage format. It doesn't have the basic hierarchy that you define, but
that could easily be created with simple semantics. We already have a bug on
speeding up .properties file access.. 

>> I do not see the connection with these property files.  Maybe there is more
you can do that name-value pairs.  If anything we should share the code that
parses xpt files. (yeah, I ripped it off.  We need to combind the two at some
point).

4) are we really sure its worth the risk/reward to completely change the file
format for a 1% startup improvement this close to mozilla 1.0? It just seems
like high risk/low reward, and not exactly a 1.0-ship-stopper :(  I think a new
format could be really great, I just want to make sure we're doing
the right thing at this stage in the game.

>> DP and his teams should weight in here.  We still have 5 weeks or so.  


Here is positive I see here:

- a text registry for xpcom has been a want for a while
- For embedding clients, this reduces the dependence on libreg. xpcom was the
biggest user of libreg. intl, plugins are the other. There is an opportunity to
eliminate the need for libreg altogether.
- we need to see what kind of footprint gain we see from this.

Since this is all under the hood of xpcom, I dont see giant risk. xpcom plugins
would be the one exception. Whats the story on that one ? Wont this break that.
well, if they are not broken already by the other changes in xpcom, they should
not be broken by this change... unless of course, they are poking the registry
themselves.
Hmm.  This isn't what I really had in mind, but then I wasn't coughing up code
either.  I was hoping to put all the factory data (rather than just
pointers-thereto) into the dhash, and then basically just blat out the
PLDHashTable structure en masse.  Reading it back in and fixing up .ops would be
the other half of the coin.

Much of the work is just turning nsContractIDTableEntry.mFactoryEntry from an
|nsFactoryEntry *| into an |nsFactoryEntry|, and then the char * bookkeeping. 
There's code in the xpt and jsxdr worlds that do that part.  (Building a
temporary string table on load whose string-data can be handed off to the new
dhash's pointers upon completion requires one enumeration of the hash table on
each of store and load.)

I don't think we need a text/human-readable registry, myself, but maybe I just
haven't seen all the things that have been blocked for the past 4 years by the
absence of one.  Microsoft's registry is binary, isn't it?
no, but microsoft has engineers working on tools to support the registry format.
 :-)

I know really care if it is text or not.  I am just in it for the speed.  If
doing a binary file buys me another few milliseconds, I am all for it.
Mike, I guess the good news is that although this patch might not agree with
you, with it, we have a pitch point where we can slap in the shaver-dump-hash code.
shaver: nsFactoryEntry seems to be about 8 words on most platforms -- pretty big
to nest in a PLDHashEntry.

Speaking of name-value pair "databases", has anyone seen bstell's in bug 116149?
 It wants to land in gfx/public, but if it's good for XPCOM too, it should go in
xpcom.  It's not huge, but it still seems a shame to have two similar things in
the tree -- code footprint counts too.  Thoughts?

I haven't actually looked at dougt's patch to see how close it is -- I'm way to
busy right now.  But I thought I'd mention the possible overlap.

/be
shaver: nsFactoryEntry seems to be about 8 words on most platforms -- pretty big
to nest in a PLDHashEntry.

>> Huh?  didn't you help neeti convert from the nsHashtable to the pldhash?

Speaking of name-value pair "databases", has anyone seen bstell's in bug 116149?
 It wants to land in gfx/public, but if it's good for XPCOM too, it should go in
xpcom.  It's not huge, but it still seems a shame to have two similar things in
the tree -- code footprint counts too.  Thoughts?

>> We should investigate potential gain using a database.  However, performance
has been a driving factor which moved us in a direction to just populate the
entire hash at startup.  


dougt: your quoting style is backwards, but I'm hip to it and am inverting:

>>shaver: nsFactoryEntry seems to be about 8 words on most platforms -- pretty
>>big to nest in a PLDHashEntry.
>
> Huh?  didn't you help neeti convert from the nsHashtable to the pldhash?

Yes, so?  You don't want to make a double hash-table's entry struct too big or
it will waste space unless overloaded, because the free entries are whole
structs, not just pointers as in the bucket array of a chained hash table.

> We should investigate potential gain using a database.  However, performance
> has been a driving factor which moved us in a direction to just populate the
> entire hash at startup.  

That's really all bstell's does, too -- it's not so much a db as an ASCII format
for reading in a bunch of name-value pair data.

/be
Blocks: 123660
That's all nsPersistentProperties is as well. Just a set of 
foo=bar 

read into a file, and then retrieved later. I don't understand why we can't just
reuse that.
My assumption is that we want to prepopulate the hashes: 

If that is not correct and we want the hashes populated on demand, lets talk
about it.  From my undestandings of this issue, slow population caused
significant disk access especially at startup.  Is there any equivelent high-use
hashtable in mozilla that does not restore the entire hash at creation/init time
that we can examine?  We can look at unused nsFactoryEntry after startup to get
a good feeling of the footprint benefit.  The size of the new component manager
registry file is about 160k.  Assuming that the in memory footprint is close to
the footprint on disk and 50% are ununsed during startup, we would save about
~80k.  We could structure the data such that the first read will populate the
required startup pieces.  

If that assuming is correct and prepopulation is the way to go, than I say
'worse is better'.  This patch gives us 'pitch points' to do whatever dumping we
want to do.  If that is to use some off-the-shelf-open-source-db, or if it is to
reuse something we have in the tree, great!  To measure performance tradeoffs,
all someone would have to do is implmented Read|WritePersistantRegistry which is
much much much simplier than having to deal with the component manager as it is
today.

Another solutions which we code investigate the cost of implmenent the
nsIRegisry interface with one of these databases your talking about.  Don't
sound like it can be done with a simple name-value db.  Dan, do you have any
thought about a faster libreg? :-)

"Persistent", not "Persistant".

/be
crap.  I misspelled that in the patch too.  At least I am consistEnt. :-)  

I have gotten some resistance to this patch based on the non reuse of database
code.  It is suggested that I try to reuse the nsPersistantProperties class.  I
have looked at this class and it has a few drawbacks:

1. First, it not optimized for reading name="comma delimited values".  What this
class does is populates a hash with name value pairs.  If I converted the
Read|Write code this class, I would be populating one hash to populate anothers.
 Furthermore there would be much more copying going on.  "Noise" maybe, but why
add to the problem.  

2. To write out the persisent data, I would have to repopulate the
nsPersistentProperties class - or worse - keep it in memory.

3. Not a long term problem, but worth mentioning, nsPersistantProperties::Save()
is not implemented.

I just don't see a really good fit here.  If I am missing something please point
it out.

well, you could use name="foo,bar,baz" but what about creative use of keys
i.e.

comp1.contractid=abcd
comp2.cid=abcd

I guess I don't 100% understand the structure of the data you're storing.

Also, as far as the hashtable bit, what about having some sort of callback
mechanism every time a name value pair is encountered? I think that bstell could
also benefit from that for his font stuff - i.e. something where you have an
interface

interface nsIPairFoundListener : nsISupports {
  void pairFound(in wstring key, in wstring value);
}

you'd implement this, pass an instance to nsIPersistentProperties, and get a
callback every time a name/value pair.. ? 

As for Save() - again this is something that the implementation would benefit
both this and the font code. And while Save() might not be implemented, neither
was your entire previous streaming-database, before this bug came along :)
way to pound that square peg into that round hole! :-)

so, if I were to understand you correctly:

1. add some kind of listener callback to the nsPersistentProperties so that I
can add the entries to xpcom's hash while they are being added to the
nsPersistentProperties has.  

when all of the entries are read in, I would want to delete the
nsPersisentProperies so that i can reduce runtime footprint.  

This clearly sounds like a waste to me (for this discussion anyway).

2. Add Save() code to the nsPersistentProperties class so that the persistent
has h can be read back it.  Sounds like a required thing to have if more people
want to use this.  


per alecf's input I've been evaluating nsIPersistentProperties for storing
font summaries. I know that I can save the data in the form
font.<font identifier>.NAME=VALUE so the mechanism is adequate. My issue
is performance. Loading the entire list of all font summaries into memory
at startup using nsNameValuePairDB takes about 70 milliseconds for 200
font. Looking at the nsPersistentProperties I'd guess it would take at
least 2x longer. I already feel that 70 milliseconds is too long. Right now 
I'm looking at having a "minimal font summary" of just the font name, 
language groups (64 bits), and font file timestamp. This would be much less 
to read. Using nsNameValuePairDB I have measured this to take around 7 
milliseconds so if nsPeristentProperties was only 2-3 times slower it would 
be okay.

thanks for your input!  what is the bug that this font db reuse is being track on?
ok, I'm not specifically excited about nsPersistentProperties, what I'm trying
to do is promote code re-use. if we can find another, even better solution in
the codebase somewhere, I'd like to see us use that.

over AIM, dougt explained that his code comes mostly from jband's xpti.dat code.
With a little subclassing, he says we could get this new format almost for free.
That sounds a whole lot better than writing our new format, so we agreed to go
with that.

Brian, thanks for looking at nsPersistentProperties for your purposes. Perhaps
you might ALSO look at this xpti.dat format (dougt: pointers to the code?) -
maybe we should "abstract" it (by which I mean put generic prefixes on the
methods/classes, other than "XPT") and make it available to fonts as well?
I checked the nsNameValuePairDB code in under bug 116149. After it was
checked in alecf asked if it could be done using existing code. In an
email thread I mentioned I had talked with vidur about xml (too slow) 
and bienvenu about mork (fast but not a good match). Brendan asked if I
could replace it with some existing code today so I had not opened a
bug.

Based on the inputs I seen in this thread perhaps I should step back
slightly and rethink.

Since we are both concerned with speed I would be happy to swap ideas.

Would it help if I open a bug on font information loading speed?

Okay, I have made the xpi.dat and the compreg.dat share the same parsing code. 
The *only* different betwen the two is how the section headers are read in.  The
xpi stuff knows a bit more about how many entries are shared.  This different is
a single static C function named ReadSectionHeader.  The class is not in a file
in xpcom/ds/nsManifestLineReader.h and is NOT exported.

So, just to be verbose about the code bloat that we are talking about here.  The
new code add is much less than the code I removed.  Just off the top of my head,

New code:
three methods on nsComponentManagerImple to read and write out the persistant data.
one method as describe above to read in section headers.
four functions to support the nsIComponentLoaderManager interface.

new data:
nsComponentManagerImpl now owns an array of all of the file stat info.

Removed code:
7 functions handling registry code in the nsComponentManagerImpl
all size and moddate handling from xcdll.

Removed data:
4 registry keys
128 bits savings on all xcdll's structures.

Most of this means crap without numbers.  If someone is interested, I have a
windows build in my home dir.  

Patch coming soon.
Attached patch draft 2. (obsolete) — — Splinter Review 
Reuses manifest parsing code.
Fixes up spelling errors: ant vs. ent.

Still not tested on mac or linux.
Attachment #69727 - Attachment is obsolete: true
Comment on attachment 70445 [details] [diff] [review]
draft 2.

I don't pretend to understand everything that's happening here, but a few minor
comments:
- seems like it might be worth keeping an already-QI'd copy of the
loaderManager (from mCompMgr)
- is there no way to get an nsISimpleEnumerator directly from nsHashTable? that
sucks. I guess for bonus points you could write
NS_NewHashtableSimpleEnumerator() :)

this is great though. Nice to see this code being ripped out
Let's get this in for 0.9.9, but no rush tonight.  Doug, can you get testing
buddies on other platforms and demonstrate righteousness?

/be
Blocks: 122050
running linux build now.  This afternoon, I will kick off a mac build.
Blocks: 125617
> seems like it might be worth keeping an already-QI'd copy of the loaderManager
(from mCompMgr)

Where would this be used?

> is there no way to get an nsISimpleEnumerator directly from nsHashTable? that
sucks. I guess for bonus points you could write NS_NewHashtableSimpleEnumerator() :)

Was thinking about that, but shaver convinced me of better ways.  I want to be
able, at some point, to just get a dump of a hashtable.  When we reach this
point I will not have a requirement of this NS_NewHashtableSimpleEnumerator.



this is great though. Nice to see this code being ripped out


two minor repairs (from TRUE to PR_TRUE) and linux builds fine.
my mac sucks and is *still* building.  Stay tuned for results.
strdup - > nsCRT::strdup for mac compliation.  
Comment on attachment 70445 [details] [diff] [review]
draft 2.

>>seems like it might be worth keeping an already-QI'd copy of the loaderManager (from mCompMgr)

> Where would this be used?

here:

>Index: js/src/xpconnect/loader/mozJSComponentLoader.cpp
>===================================================================

>+    if (!mCompMgr)
>+        return NS_ERROR_FAILURE;
>+    
>+    nsCOMPtr<nsIComponentLoaderManager> loaderManager = do_QueryInterface(mCompMgr, &rv);

here: 
>+    if (!mCompMgr)
>+        return NS_ERROR_FAILURE;
>+    
>+    nsCOMPtr<nsIComponentLoaderManager> loaderManager = do_QueryInterface(mCompMgr, &rv);
>+    if (NS_FAILED(rv))

here:

>+    if (!mCompMgr)
>+        return NS_ERROR_FAILURE;
>+    
>+    nsCOMPtr<nsIComponentLoaderManager> loaderManager = do_QueryInterface(mCompMgr, &rv);
>+    if (NS_FAILED(rv))


:)
Oh!  Of course.  Fixed.  
Status:

Windows works fine.  Been runing with it for about a week.
Linux works fine.  Smoketest runs fine.
Mac builds fine.  startups then crashes in a Layout.  Maybe a bad pull.  I will
try updating and rebuilding again.

New patch coming which will include alecf's suggestions and the build
differences mentioned above plus makefile.win love.

After thinking about this for some time, and confirming with Alec, we agree that
this we should punt on this patch for 0.99.  There is too much risk without
enough bake time.  Lets carpool this patch in after we branch.


although, I would like to land this after the tree branches, I still would like 
to have reviewers.  Alec, Jband, :-)

I might be of use reviewing the code.  I have no time now, but in a week or two
I might make time, if that is soon enough.

This may be old information, but quite some time ago when I tried to change the
structure of the libreg file to satisfy some new requirements, I was shown and
convinced in the code that there were at that time significant other parts of
mozilla directly poking around in the component.reg file and that changing just
the organization within the file would break them / cause rewrite.  Perhaps the
code has changed since then.  Or it might mean a bit more work to be done.  I
doubt these dependencies would be exercized in startup, but complete analysis of
who calls libreg ought to find them.
I was hoping to land within a week. :-)

What are you requirements?  lets talk.
Attached patch patch 3 (obsolete) — — Splinter Review 
fixes caches component loader manager in js component loader.
fixes build problem with the static build.
Attachment #70445 - Attachment is obsolete: true
Comment on attachment 70445 [details] [diff] [review]
draft 2.

so overall this looks fine  - this review has introduced me to some work we
probably need to do at some point:
I see a few places where you could be using nsXPIDLCString, but I see that it's
just code that has been re-indented because the code structure has changed...

I also see that we could be storing the nsFactoryEntry structs in some kind of
arena, since we cache so many of them.. nsFixedSizedAllocator would be put to
good use here. 

only real review-blocking issue I have is with nsIComponentLoaderManager - use
interCaps not LeadingCaps!
Attachment #70445 - Attachment is obsolete: false
Comment on attachment 71403 [details] [diff] [review]
patch 3

I hate it when that happens... wrong patch.
Attachment #71403 - Attachment is obsolete: true
Attached patch patch 4 (obsolete) — — Splinter Review 
addresses alecf's concerns.
fixes the static build bustage.

tested on mac windows linux and linix static build.
Attachment #70445 - Attachment is obsolete: true
Comment on attachment 71416 [details] [diff] [review]
patch 4

ignore netwerk/base/public/nsIURI.idl change.
This is an important bug for 0.9.9.  Doug, where are we with this?
Whiteboard: [driver:blizzard]
Hey Chris,
If your willing to accept the risk for 0.99, i am fine with landing it.  See my
notes above.

Status - need an official r/sr from alec who reviewed patch 3.  patch 4 address
his concerns.  need another r/sr from someone.  Maybe jband or shaver, both of
whom said that they would review this patch.  At that point, I need a a= from
you, bliz.
I have a problem with landing this in 0.9.9: I don't think it's worth the risk
and I think we're better off putting out a good 0.9.9 release and letting this
patch's oddities shake out over the course of a milestone
I'm minusing this for 0.9.9.  Seems higher risk than what we want.
No longer blocks: 122050
Keywords: mozilla0.9.9 → mozilla0.9.9-
Target Milestone: mozilla0.9.9 → mozilla1.0
If we aren't taking this in 0.9.9, how can we take it in 1.0?  We have zero full
milestones to bake it and gather talkback.  I don't think drivers will go for
it. I say now or 1.1.  Blizzard says not now.  That says 1.1 to me.  Doug, take
it up with drivers@mozilla.org if you want now.  I don't buy 1.0 as the TM.

/be
sounds find by me.  1.1.
Target Milestone: mozilla1.0 → mozilla1.1
Attached patch Patch v.5 (obsolete) — — Splinter Review 
Addresses threadsafety of loader.
Attachment #71416 - Attachment is obsolete: true
Comment on attachment 72911 [details] [diff] [review]
Patch v.5

I'll try to review it tomorrow sometime, but it looks like there's a lot of
stuff in there that I can't quickly associate with threadsafety issues.  Is
this the right patch?
sorry to be vague.  That last patch made the nsNativeComponentLoader protect its
mDeferredComponents array as well as making it a threadsafe isupports.  

Isn't mDeferredComponents only used during autoregistration?  I thought our rule
was that XPCOM startup had to be run single-threaded.

More tomorrow, still not sure why all the registry stuff is needed to make the
component loaders threadsafe.  Maybe it'll be clearer after some sleep. =)
the array may be touched if you call AutoRegisterComponent.  We could avoid this
critical section if we required that AutoRegisterComponent can only occur on the
main thread.

This patch is not absolutly required to make everything in the com part of xpcom
world threadsafe.  
instead of things like +        printf("No Persistent Registry Found.\n");  in 
ifdef DEBUG, should we use NS_WARNING (still inside the ifdef...)?
I made this point in a posting n.p.m.xpcom. It seems a good idea to consider if
the component registry can be kept on the disk as much as possible.

If it's feasible, we should consider memory mapping this file so it doesn't need
to be held in memory. If necessary supplement the memory mapping with some
lookup tables, but don't load the whole lot in.
adam, it has been considered.  see  #15, 22.  Also read some of the old xpcom
news postings.
mmap doesn't keep file data out of memory, on any system I know of.  It may save
us a copy, iff we don't need to touch the structures at all, which is hard in
the case where we have pointers between structures (as in this case).
I know mapping doesn't keep it out of memory but it does mean you have 1 copy of
the registry instead of two - one on disk and one in memory. That's a footprint
win because you're not consuming real memory or swap to replicate the data. 

Further, on some embedded devices (e.g. iPaq), memory and storage are one and
the same so it doesn't make sense to consume space with two copies of the
registry when space is so restricted to begin with.

The challenge is producing a data format which combined with a cache or lookup
table is as efficient as dragging the whole thing into memory.
adam - put together a patch which does as you suggest and gets some real data. 
We can guess all day about this and that.  Until someone shows that there is a
zero sum game (or better) mapping in a file, this is just wasting everyone's
time - time which could be spent reviewing and testing the attached patch which
actually does reduce bloat and startup time.
I don't want to hold up this bug with my suggestion, but it may be worth bearing
in mind the next time registry format changes. I can attach a simple sample to
demonstrate a memory mapped approach using a fixed size records but obviously
its no more than a proof of concept.
Whiteboard: [driver:blizzard] → [driver:blizzard][adt2]
Attached patch patch 6 (obsolete) — — Splinter Review 
updated to tip.
Attachment #72911 - Attachment is obsolete: true
Attached patch patch 7 — — Splinter Review 
Includes DP's suggestions.
Attachment #85615 - Attachment is obsolete: true
Comment on attachment 86394 [details] [diff] [review]
patch 7

r=dp
Attachment #86394 - Flags: review+
the target milestone for this is 1.1.alpha. does this mean we don not want to
land this on the 1.0 branch? if so, pls change the the keyqord to nsbeta1-. thanks!

is this perf improvement for linux only?
Blocks: 143047
Whiteboard: [driver:blizzard][adt2] → [driver:blizzard][adt3 RTM]
> is this perf improvement for linux only?

no.  all platforms.
Attachment #86394 - Flags: superreview+
Comment on attachment 86394 [details] [diff] [review]
patch 7

sr=waterson
3-4% Ts improvement reported from tb.  Marking fixed.  

If you find problems related to this checkin, please open seperate bugs.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0.1
Resolution: --- → FIXED
This checkin have added a "might be used uninitialized" warning:

+xpcom/components/nsCategoryManager.cpp:72
+ `nsresult status' might be used uninitialized in this function

thanks.  I fixed that just now
Setting All/All per Comment #77.
OS: Linux → All
Hardware: PC → All
Whiteboard: [driver:blizzard][adt3 RTM] → [driver:blizzard][adt3 RTM][wgate]
Component: XPCOM Registry → XPCOM
QA Contact: rayw → xpcom
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: