104988 - cache string bundles in certain callers to improve message compose performance

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, defect)

Description

[(not reading, please use [e-mail] instead)]

cache string bundles in certain callers to improve msg compose performance

while working on msg compose performance, I noticed that we pay a significant
hit if our call to create a string bundle results in a cache miss.

building a string bundle isn't cheap.

another alernative is to never evict certain (or any) string bundles from the
bundle cache.

for example, evicting necko.properties is bad, since we know we are going to
reload it.

on the subject of string bundles, composeMsgs.properties is the biggest one
we've got in mailnews.  if that gets evicted, and we need to load it again for
the compose window, we pay the price.

I'm going to break it apart, so that the strings we use on new compose window
are in one properties file, and the rest, infrequently used strings, are in
another bundle.

Comment 1

[Alec Flett]

ya know, we could always just increase the size of the string bundle cache. I
just arbitrarily hardcoded it to 10 bundles. there's a #define
MAX_CACHED_BUNDLES that can be changed very easily. (No, I didn't put it in a
pref - long story but basically string bundles can't use prefs until I clean up
some other dependencies)

Try a few values...see if you can find a 'sweet spot'

Comment 2

[(not reading, please use [e-mail] instead)]

when I get back to this, I'll try to find a sweet spot.

I'll also look into breaking up composeMsgs.properties.

Comment 3

[(not reading, please use [e-mail] instead)]

alecf recently bumped up the # from 10 to 15, because that's how many bundles 
we create at startup.

I'll keep this bug open, because tracks string bundle abuses in mailnews.

Comment 4

[scottputterman]

I'm minusing this because it sounds like Alec's fix may have solved the worst
part of the problem for us.  If it's still important for us to make changes, let
me know.

Comment 5

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 6

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 7

[:aceman]

Is this bug still relevant? Is the caching still done in the way it was when this bug was filed? Is the composition still hit by this in any significant way?

Comment 8

[Magnus Melin [:mkmelin]]

My would doubt it has any relevance.

Comment 9

[Magnus Melin [:mkmelin]]

Let's close this. Should move to Fluent anyway.