Closed Bug 510990 Opened 15 years ago Closed 13 years ago

nsIOService::NewURI is horribly slow

Categories

(Core :: Networking, defect, P2)

x86
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 268200

People

(Reporter: taras.mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [ts])

0.2ms on n810 per call. This gets called 100s of times on startup
Whiteboard: [ts]
do you have any information from your profiling work as to what it's actually doing that is slow?
That's without any xpconnect overhead?
(In reply to comment #2)
> That's without any xpconnect overhead?

without, this is from C++, that's the sad part.
per taras, this needs some shark-ing, should not be hard to fix. jduell: can you take a look?
What I just sent Taras:

So I just tried profiling the parse of 100 copies of xul.css with shark.  On my macbook pro, with a 20us sampling interval, I get about 23000 samples when I do this; that puts the whole parse at 460ms or so. ParseURL is about 26% of the samples.  All percentages that follow are percentags of the ParseURL time, which means percentages of 6000 samples; I'd take anything under 5% with a bit of a grain of salt.

10% gathering up the url characters into an nsString.
8% the getService call to get the IOService.
3% converting the URI string to UTF-8.
some random stuff under 1% each that's clearly shark noise.

That leaves about 73% under the NewURI call on the IOService.

3% getting the scheme out of the URI string
2% getting the chrome protocol handler
10% creating an nsStandardURL using do_CreateInstance in
    nsChromeProtocolHandler::NewURI
10% nsChromeRegistry::Canonify (largely GetPath followed by
    nsUnescapeCount on the path)
47% nsStandardURL::Init.

Under Init, there's some GetOriginCharset, but most of the time is under SetSpec calling BuildNormalizedSpec and ParseURL.  Things like nsBaseURLParser::ParseURL, nsStdURLParser::ParseAfterScheme, nsIDNService::ConvertToDisplayIDN, etc. nsStandardURL::nsSegmentEncoder::EncodeSegmentCount, a lot of which is unescaping, creating nsFixedCStrings, etc.

Possibly more interesting is the bottom-up profile:

4% memcpy
4% net_CoalesceDirs
4% NS_EscapeURL
4% nsUnescapeCount
4% nsStandardURL::BuildNormalizedSpec (again time in; time under is more like 20%).
2% UTF16 to UTF8 conversion.
2% nsBaseURLParser::ParsePath
2% malloc
2% nsBaseURLParser::ParseURL
2% net_FilterURIString
2% free
etc, etc.

Sort of more of the "just running too much code" thing.  :(
When I talked to Darin a couple of months ago, he mentioned that Chrome uses a URI library that's easy to split out, in the hopes that other browsers might pick it up (and we'd all parse URIs the same way).  Perhaps it's worth a quick benchmark/compare to see if it performs a lot better.   I know biesi thought that porting it might be more fuss than it's worth, but if we're really getting killed by our own URI logic, and it's a lot of work to fix, it might be worth it after all...
Priority: -- → P2
Blocks: 447581
This is closely related to (and virtually a dup of) bug 268200
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.