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 On Mon, Jan 21, 2013 at 4:09 AM, Bill McCloskey <[email protected]>wrote: > > bhackett's comment > > https://bugzilla.mozilla.org/show_bug.cgi?id=821040#c5 does not > > confirm. > > Anyone else try to reproduce? > > To clarify, we know for sure that the problem was caused by switching to a > threadsafe build. We don't know why threadsafe builds are slower. I saw > some results that suggest that the performance difference is caused by > source compression. However, it seems very machine-dependent. I saw the > source compression regression on one computer; on another computer, there > was a smaller difference between TS and non-TS, and it wasn't caused by > source compression. Brian saw no difference between TS and non-TS. > > Someone should probably ssh into whatever computer is reporting the > results and isolate the problem. I don't think we should disable source > compression anywhere unless we know what's going on. > > -Bill > _______________________________________________ > 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
