String literals are used heavily in run-time reflection, e.g.:
Object.getOwnPropertyDescriptor(obj, 'foo')
typeof(x) === "object")
String literals are also used to represent symbolic values in JS. It's
not uncommon to see things like:
var Days = { Monday:'Monday', Tuesday:'Tuesday', ... }
Where later |Days.Monday| is used as a symbolic constant. We shouldn't
slowpath these kinds of use cases. They are valuable for
well-structured programming and we don't want to discourage the use of
these kinds of patterns by regressing their performance.
Atomizing string literals is definitely a good idea, although it might
make sense to put a length limit - say 32 or 64 chars (do we already do
this, maybe?).
Kannan
On 2/7/2014, 9:06 AM, Jan de Mooij wrote:
On Fri, Feb 7, 2014 at 2:34 PM, Nicholas Nethercote
<[email protected]> wrote:
A more general question: what exactly is atomization for? Is it purely
for cases where we want to avoid duplicating strings (with the option
of interning)? The fact that lots of data structures (e.g. ParseNode)
have JSAtom* fields suggests that it's not this simple. This is
something I've never entirely got my head around.
Atoms also make string comparisons fast: two atoms have the same chars
iff their pointers are equal. So if you have an obj[foo] expression,
we can atomize foo, convert it to a jsid, then walk over all shapes
and do a single jsid comparison to find the right one. I think the
frontend also uses this for various HashMaps that have JSAtom* as key,
see Parser::noteNameUse for instance.
String equality is also easy for the JITs to inline when you have two
atoms, see MacroAssembler::compareStrings. If we stop atomizing string
literals we will probably take a slow path there, but I don't know how
much that will affect our main benchmarks...
HTH,
Jan
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
