On 05/03/2016 11:11 AM, Jakob Stoklund Olesen wrote:
On May 3, 2016, at 10:56, Boris Zbarsky <[email protected]> wrote:
On 5/3/16 1:28 PM, Jakob Stoklund Olesen wrote:
It is not assertions that make unoptimized C++ really slow, it is the lack of
inlining which is critical to clean up template abstraction goop.
It depends on the assertions. In the case of the JS engine, the particular
assertions under discussion change the algorithmic complexity of many
algorithms, which makes them much slower in practice.
In particular, the "release+asserts" configuration (--enable-debug
--enable-optimize) is much slower than the same thing without --enable-debug in the case
of SpiderMonkey.
That makes sense. Would it be worthwhile to put the worst offenders under their
own flag so they could be disabled in an optimized build?
LLVM had an EXPENSIVE_CHECKS macro for that kind of assertion, but I don’t
think they use it any more. People would rarely enable it, so the expensive
assertions had a tendency to bit rot. I think if they had been enabled by
default, they might have stayed in.
Yes, this would be worth doing, but would require some effort. I think
we can keep them from bitrotting by running with them on in automation.
I would say that a debug build should always have them compiled in, but
the expensive asserts could do a dynamic check before executing.
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
