Status
()
People
(Reporter: vlad, Unassigned)
Tracking
(Depends on 1 bug, Blocks 1 bug)
Firefox Tracking Flags
(Not tracked)
Details
(Whiteboard: [ts])
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
|
Reporter | |
Updated•10 years ago
|
Whiteboard: [ts]
|
||
Updated•10 years ago
|
|
||
Comment 1•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...
|
|
Reporter | |
Comment 2•10 years ago
|
||
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?
|
|
Reporter | |
Comment 4•9 years ago
|
||
Nope, haven't touched this in a while. It's worth a look.
|
||
Comment 5•8 years ago
|
||
(In reply to comment #4) > Nope, haven't touched this in a while. It's worth a look. Did you ever take that look?
|
||
Comment 6•8 years ago
|
||
> 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.
|
||
Comment 7•8 years ago
|
||
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.
|
||
Comment 8•8 years ago
|
||
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.
Description
•