I've been playing with sorting the output of directory listings using the collation stuff. Using strcmp on prunichar*'s, starting my command line test program + sorting /dev takes 3 seconds. Using CompareString on a cached nsICollation takes 22. The only place in the code which appears to use CompareString is the XULSortService, which is known to be very slow (I have jprof profiles showing that this is why the xul directory viewer is very slow - see bug 69185). Interestingly, http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULOutlinerBuilder.cpp#1779 appears to just call CompareRawSortKey on the prunichar* directly. Hyatt, is there a reason for this? CompareString goes to a lot of trouble to get the sort keys, and (on unix) calls strxfrm. Is there a subtle reason why we just can't call strcoll after setting the locale, and do the equivalent for other platforms?

ftang: can you answer reporter's question? ==== assigning to ftang.

Yes, we know nsCollation::CompareString is slow, and ideally you should generate sort key by using the same interface, cached the sort key and compare the generated sort key instead. We did that on Mail/News subject panel already. The answer to this bug is- don't use CompareString, cached the generate sort key instead. mark this bug wontfix.

Sigh. If you don't want to fix this bug, can you add a comment to the interface file deprecating this routine, then?

Verifying it for now as won't fix. Please re-open in case someone disagrees.

Reopening because I fixed this as part of bug 207634.

*** This bug has been marked as a duplicate of 207634 ***