Closed
Bug 510990
Opened 15 years ago
Closed 13 years ago
nsIOService::NewURI is horribly slow
Categories
(Core :: Networking, defect, P2)
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
Reporter | ||
Updated•15 years ago
|
Whiteboard: [ts]
Comment 1•15 years ago
|
||
do you have any information from your profiling work as to what it's actually doing that is slow?
Comment 2•15 years ago
|
||
That's without any xpconnect overhead?
Reporter | ||
Comment 3•15 years ago
|
||
(In reply to comment #2) > That's without any xpconnect overhead? without, this is from C++, that's the sad part.
Comment 4•15 years ago
|
||
per taras, this needs some shark-ing, should not be hard to fix. jduell: can you take a look?
Comment 5•15 years ago
|
||
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•15 years ago
|
||
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...
Updated•15 years ago
|
Priority: -- → P2
Comment 7•13 years ago
|
||
This is closely related to (and virtually a dup of) bug 268200
Reporter | ||
Updated•13 years ago
|
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.
Description
•