267532 - Excessive calls to IsDBCSLeadByte from net_CoalesceDirs?

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Darin Fisher]

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.

Comment 1

[Andreas Otte]

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

Comment 2

[Darin Fisher]

Attachment: v1 patch

Comment 3

[Darin Fisher]

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.

Comment 4

[Darin Fisher]

> so I don't think we can safely remove this IsDBCSLeadByte check.

I meant: "so I _do_ think we can ..."

Sorry about that! ;-)

Comment 5

[Darin Fisher]

fixed-on-trunk