13488 - [perf] Optimize nsDateTimeFormatWin::FormatTMTime()

Status: RESOLVED FIXED

(Core :: Internationalization, defect, P3)

Description

[Chris Waterson]

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.

Comment 1

[nhottanscp]

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.

Comment 2

[nhottanscp]

Accepting, will cache locale data regardless of the nsILocale value (NULL or
not), no client side change required.

Comment 3

[nhottanscp]

Checked in the change for three platforms.