* I profiled doing autocomplete in the toolbar the other day, and ~32% of the time was spent converting data back and forth between UTF8 and UTF16. Now, nsIAutoCompleteItem stores its value in UTF16 (nsAString). nsIURI gives us all URIs as UTF8 (nsACString) because URIs can more or less only be composed by ASCII characters anyway, with a few exceptions. Not only would having a nsIAutoCompleteItem that stored its internal value in UTF8 save us memory, it will also improve performance, because we do *a lot* of string comparisons. * There are also other inefficient things going on, like unwrapping a whole nsISupportsArray just to append every element into a nsIAutoCompleteResults array. * We seem to implement all of the nsIAutoComplete* interfaces (see URL) so we have no real dependency on any gecko-code for autocomplete. We just need to write some customized and more efficient classes. My goal is to deCOMify the autocomplete code as much as possible. This would be the first step to make it less XPCOMy, and more Objective-Cish.
Forgive me for not understanding a lot of comment 0 (lack of programming skills does that), but wouldn't this bug not matter at all if we do bug 340611?
I suppose this will lead to bug 340611, or even fix it. I don't really care whether the result is in "cocoa" (objc?) or if it'll be objc++, but I'd like to incrementally improve the code to use less XPCOM.
I'd dup this to bug 340611, really.
(In reply to comment #3) > I'd dup this to bug 340611, really. We can do this, but then I just want to point out that this is something that will happen incrementally. It would be too big to convert it all to 'cocoa' in one patch.
*** This bug has been marked as a duplicate of 340611 ***