On Fri, Feb 7, 2014 at 8:31 AM, Kannan Vijayan <[email protected]> wrote: > > 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?).
We don't. If there were some places where we might atomize and might not, then we couldn't use pointer-equality for string-equality, thus losing a major advantage of atoms. (Thanks to Jan for reminding me of this advantage.) The reason I've been thinking about this is that the atoms table can get large. In my current browser session the atoms table for the main JSRuntime is 8 MiB. That's not a big deal on desktop, but it is a big deal on B2G. But this seems hard to change. However, it's not the only cost -- there's also the hashing (time) cost. For very long strings this cost is high. I wonder if we should change AtomHasher to look at only the first N and last N chars in the string when computing the hash, where N might be, say, 100. Nick _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
