There's no good reason that turning on threadsafe should slow down the JS engine. It should speed it up, not just for background compilation but for background finalization and is necessary for other stuff we need in the future (e.g. parallel arrays). Any configuration in which a threadsafe build is noticeably slower than a non-threadsafe build indicates a bug in the engine, and what we need right now is a better handle on the problem rather than a workaround. (Or maybe I should just start perf testing on the awfy box.)
Brian On Mon, Jan 21, 2013 at 4:42 AM, Bobby Holley <[email protected]> wrote: > For the moment, I think it's pretty important to be testing JS_THREADSAFE > builds, because those are what we ship to users. Basing AWFY on the > theoretical of a build configuration we can't ship is a significant hit to > its value as a metric IMO. > > That being said, I've been working on and off on bug 455548 for a number of > reasons, a large one being that I was under the impression that it could > let kill the JS_THREADSAFE define and speed up the entire JS engine. I'd be > curious if this is something people would want to do if the Gecko > dependency were removed, or if the IM compilation stuff is enough of a win > that it would stay on anyway. > > Cheers, > bholley _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
