On 1/20/2013 1:37 PM, Gregory Szorc wrote:
I'm writing to the Platform list as a developer that maintains a
significant amount of JavaScript for Firefox. Much of the JavaScript I
maintain is for large backend features, such as Sync and Firefox
Health Report. These features are thousands of lines of code (mostly
JavaScript) and interact with many systems in Firefox. These backend
systems tend to perform many of the same tasks, so there is code
shared between them in the form of JSMs. To reduce redundant code
(therefore bugs) and development costs, there is obviously the
incentive to share as much code as possible.
The use case from which I'm coming from here is my ongoing project to
replace Thunderbird's MIME parser and processing library with a pure JS
implementation. The architecture of this library will end up looking
more or less like as follows:
mimeParseCore.js, msgParserCore.js, fooBarConverter.js, etc.: The actual
implementations of the core logic, which assume they are all installed
into the same global object.
MimeParser.jsm: a JS module that loads the above via a subscript loader
(C.u.import doesn't quite work for what I need).
[There will be another API face for Worker scripts, but I haven't gotten
that far ahead in design yet]
mimeComponents.js: an XPCOM component that implements some interfaces
using the MimeParser.jsm API.
Furthermore, there appear to be some scenarios where crossing
compartments has a horrible effect on performance. For example, it is
my understanding that crossing compartments can sometimes copy data. I
believe this always holds for strings. See bug 806087 for example.
Hundreds of MBs of "string-chars/huge" are seemingly being copied
between JSMs/compartments. While this specific bug number is resolved,
the underlying copying issue remains AFAIK.
Cross-compartment strings are the biggest pain point I think in CPG.
Most of my MIME parser's cross-compartment workflow can be described as
essentially "In compartment B, concatenate strings from compartment A,
do some string searching, and return objects largely composed of
substrings of compartment A's strings with perhaps some concatenation of
temporary strings generated in compartment B." In a more general
terminology, much of my cross-compartment usage is migratory: data tends
to originate in one compartment, move to another compartment (and remain
unused in the original), and then move back to the original, never to be
used again in the second compartment.
I do recall one particularly annoying bug in Gloda, where CPG caused
this seemingly innocuous line of code to eat up CPU and memory:
this.output[key] += inputString;
The output variable was a cross-compartment wrapper, so the JS engine
ended up having to flatten the string for each input addition, which was
being chunked in either ~80-byte or 1,024-byte chunks. If it were
possible to have strings cross-compartments that don't require
flattening and excessive copying, that would make the lives of add-on
authors in a CPG world much easier.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
