Closed Bug 166906 Opened 22 years ago Closed 15 years ago

Make more efficient string converter mechanism

Categories

(Core :: XPCOM, defect, P3)

x86
All
defect

Tracking

()

RESOLVED INCOMPLETE
mozilla1.4beta

People

(Reporter: john, Assigned: john)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

We do a number of string conversions in Mozilla: UCS2<->UTF8, URL encoding and
decoding, uppercasing/lowercasing, search and replace, charset conversion, BIDI,
and Arabic Shaping are a few.  By consolidating the system for converters we can
help achieve several important effects: ease of writing / understanding
converters, efficiently chaining one converter to another to produce multiple
conversions on a string, minimizing mallocs and string copies, and even using
the same filters both for strings and input streams.

Current converters fall into two categories, those that create a buffer and copy
into it (sometimes twice, to avoid excessive memory usage), and those that
append into a string.  Both versions as their primary problem create extra
intermediate copies of a string when you try to chain conversions together; and
the former version requires one or two mallocs in all cases as well.

I suggest the creation of an abstract converter interface that:
- works with strings (nsAString in, nsAString out)
- allows chaining one converter to another with a minimum of mallocing
- makes it easy to implement a new conversion
- has a simple syntax for use (hopefully something like
FilterA(FilterB(FilterC(str))) would work)

Being able to work with Input/OutputStreams might be nice as well.

nsAStringGenerator does not allow chaining or streams but does (or can) solve
all the other requirements.  I have been working on one that does solve the
other requirements.
I have a solution here which involves char filters, which can be chained
together and which pretty much push the data down the line, changing it as they
see fit, until it ends up in the destination string.  jag has suggested adding a
more pull-based mechanism (like an InputStream) and I am investigating.

It needs some compiling before I want to post it.  This bug is sort of a
placeholder for it right now.
Status: NEW → ASSIGNED
Blocks: 151762
Keywords: perf
Blocks: 136676
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
QA Contact: scc → string
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.