UTF8 to UTF16 conversion showing up in startup profiles

RESOLVED INCOMPLETE

Status

()

Product:
Core
Component:
General
Type:
defect
Status:
RESOLVED INCOMPLETE
Opened:
10 years ago
Updated:
7 years ago

People

(Reporter: vlad, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Version:
Trunk
Platform:
x86
macOS
Points:
---
Dependency tree / graph

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
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: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.