510990 - nsIOService::NewURI is horribly slow

Status: RESOLVED DUPLICATE of bug 268200

(Core :: Networking, defect, P2)

Description

[(dormant account)]

0.2ms on n810 per call. This gets called 100s of times on startup

Comment 1

[Dietrich Ayala (:dietrich)]

do you have any information from your profiling work as to what it's actually doing that is slow?

Comment 2

[Benjamin Smedberg]

That's without any xpconnect overhead?

Comment 3

[(dormant account)]

(In reply to comment #2)
> That's without any xpconnect overhead?

without, this is from C++, that's the sad part.

Comment 4

[Dietrich Ayala (:dietrich)]

per taras, this needs some shark-ing, should not be hard to fix. jduell: can you take a look?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 6

[Jason Duell]

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...

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

This is closely related to (and virtually a dup of) bug 268200