Excessive calls to IsDBCSLeadByte from net_CoalesceDirs? It looks like all callers of net_CoalesceDirs may be passing UTF-8 strings, which means that the IsDBCSLeadByte calls made by that function may be unnecessary. bryner has found that these calls show up on Quantify results indicating that there might be a significant performance win if we can remove them. I suspect that IsDBCSLeadByte might be leftover from when we used to pass platform specific multi-byte strings through nsIURI. we need to verify that we are indeed only ever passing UTF-8 (or ASCII) to net_CoalesceDirs, and then remove it. NOTE: if we ever unescape strings before passing them to this function, then my assertion would be false.
Severity: normal → minor
Keywords: helpwanted, perf
Target Milestone: --- → Future
I agree, this is most likely a leftover from old times. However we also most likely feed already unescaped strings to net_CoalesceDirs, some stuff in malinews comes to mind. That code might be broken because of that, but I once tried to fix some of that and broke the rules-stuff in mailnews in the process because storage of the rules depended on those broken escape-unescape sequences. Bottom line: Those instances will be hard to find and even harder to fix ...
15 years ago
In nsStandardURL::Resolve & BuildNormalizedSpec, calling net_CoalesceDirs is one of the very last things that we do before returning the result to the caller. In fact, in those cases the buffer is already UTF-8 (or ASCII), so I don't think we can safely remove this IsDBCSLeadByte check.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.8beta
> so I don't think we can safely remove this IsDBCSLeadByte check. I meant: "so I _do_ think we can ..." Sorry about that! ;-)
Attachment #164485 - Flags: superreview?(bryner) → superreview+
15 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.