73.15 KB, text/html
The constructor of nsStandardURL::nsSegmentEncoder took about 0.5% of the non-idle main-thread page load time in a profile I did on a live list of URLs similar to jrgm's tests. Most of the callers were for the construction of URLs for image loads. Most of the time spent is within the charset converter manager code. I think we should either make the ccm a lot faster or make nsStandardURL cache encoders (although one might think that would be the point of the ccm).
i imagine optimizing the ccm would benefit other consumers as well, so that gets my vote.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
Most of the calls to the ccm come from this one call site. I'd love to make lots of changes to the ccm (for performance and for code size/less xpcom), but the real problem here is that we shouldn't be re-fetching the decoder for every image uri in the document. Could there be an nsIOService::newURI variant that takes an encoder rather than a charset string?
no, that's not really an option for a couple of reasons: 1) nsIOService::newURI maps to nsIProtocolHandler::newURI and nsIProtocolHandler is frozen. 2) we need to be able to provide the charset via nsIURI::originCharset ok, so how about we put together our own little cache of charset converters. we could just keep around a simple linked list of the last 5 charset converters used. that would be fairly trivial to implement and should be enough of an optimization. we also don't need to worry about threadsafety here :)
dbaron: if we only wanted to optimize this codepath for ASCII URLs, we could simply delay calling into the ccm until mEncoder is really needed. we are already scanning the URL text to determine if calling into mEncoder is even necessary, so it would be trivial to delay initialization of mEncoder.
Target Milestone: mozilla1.1beta → Future
From looking at the code all the CCM stuff is long gone, so this bug is likely moot. Suggest it be closed as WFM
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.