Closed Bug 506431 Opened 16 years ago Closed 13 years ago

UTF8 to UTF16 conversion showing up in startup profiles

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: vlad, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

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
Depends on: 506430, 94199, 196843
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.
Blocks: 447581
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
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.