Closed Bug 13488 Opened 21 years ago Closed 21 years ago
[perf] Optimize ns
Date Time Format Win::Format TMTime()
If this is not a mailnews performance blocker now, it soon will be. This function is terribly expensive, mostly because of two calls: 1. The call to the component manager that creates the platform charset (line 167) 2. The call to the platform charset to get the default charset for the locale (line 171). RDF creates and holds on to a single date/time formatting object for the entire time that the app is run. Can we alter the nsDateTimeFormatWin to cache the default charset, as well? It seems silly to have to go fetch it each time we want to format a string. It's not going to change, is it? Performance implications are dire: this function is called once for every date that is displayed in the mailnews threadpane. It currently accounts for 15% of the time it takes to construct the RDF content model on a medium (~600message) sized folder.
Collation interface nsCollationWin caches those data. I can change date format interface similar to collation. It is also possible for the caller to cache nsILocale instead of passing NULL (which creates application locale every time). Please check how match does this improve the performance.
Accepting, will cache locale data regardless of the nsILocale value (NULL or not), no client side change required.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Checked in the change for three platforms.
You need to log in before you can comment on or make changes to this bug.