Closed
Bug 166906
Opened 22 years ago
Closed 15 years ago
Make more efficient string converter mechanism
Categories
(Core :: XPCOM, defect, P3)
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.
Assignee | ||
Comment 1•22 years ago
|
||
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
Assignee | ||
Updated•22 years ago
|
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
Updated•15 years ago
|
QA Contact: scc → string
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Updated•3 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•