All of our parsers are UTF16, but all of our files are UTF8. The conversion is showing up between 5% and 8% in a warm startup profile. There are a couple of ways to fix this, and we should look at all of them. - Speed up UTF8 to UTF16 conversion. This is straight C code now, and could probably be made much faster -- bug 506430 - Fastload XBL -- bug 94199 (?) - Fastload CSS -- bug 196843
10 years ago
Is it worth trying to make our chrome UTF16? That's probably easy to do at build-time, although you'll pay an I/O price...
Yeah, I thought about that... tried a quick hack using iconv, but that didn't work out too well. It would probably help in the warm start case, but hurt in the IO-bound cold start case, but I'm just guessing there.
Depends on: 512272
Vlad, have you rerun these numbers since we fixed Bug 506430?
Nope, haven't touched this in a while. It's worth a look.
(In reply to comment #4) > Nope, haven't touched this in a while. It's worth a look. Did you ever take that look?
> Did you ever take that look? Sounds like he didn't, and he now doesn't work for Mozilla. Glandium might be interested in this bug, however.
I don't remember having spotted so much time spent on such conversions during warm startup when i looked some time in Q3 or Q4 2010 ; but I can surely take a look.
what about UTF8 parsers instead of UTF16?
I think this bug has outlived its usefulness.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.