1127095 - Much slower than v8 on function creation microbenchmark

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Sean Stangl [:sstangl]]

Attachment: str-concat-test.js

The attached microbenchmark is a reduced version of Shumway's createCompiledFunction(), which is extremely hot during slow Shumway startup. The benchmark concatenates a bunch of strings, then feeds them into |new Function()|.

Performance on the microbenchmark is currently as follows:
> SM: 1.067s
> d8: 0.136s

Optimizing this microbenchmark should make headway toward improving Shumway startup.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Profile says 60+% of the time is under CompileFunctionBody.  Lots of Parser<FullParseHandler> stuff under there.  Presumably if we could get away with just doing a SyntaxParseHandler parse here that would help.

Even when the functions are called, the CompileFunctionBody is still about 46% of the time...

One curious thing about this testcase.  Why does it create a new Function which when called just returns another function object?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Also, is your actual use case like this, where you create a bunch of functions all with the same function body?  Because if I pass "bodies[i % bodies.length] + i" as the second argument to createCompiledFunction, the SpiderMonkey time stays about the same but the V8 time goes up by a factor of 15 or so, putting it at well over 2x slower than SpiderMonkey.  So it seems like you're just hitting some sort of Function constructor cache in V8, which is only relevant to your real-life use case if your function bodies do in fact get repeated.

Comment 3

[Sean Stangl [:sstangl]]

Answered on IRC last week. In summary: this is a synthetic benchmark that assumes that a cache isn't being used; Shumway has its own cache to prevent regenerating identical functions; Shumway should remove the level of indirection in generated functions.

Comment 4

[Till Schneidereit [:till]]

(In reply to Sean Stangl [:sstangl] from comment #3)
> Shumway should remove the level of indirection in generated functions.

Does that cause any actual slowdown?

The reason we're using it is because before ...rest there was no good way to invoke the Function constructor with a variable number of arguments. Which we have to do to compile functions without statically knowing their parameters count.

Note that we can probably just change this to use eval instead of new Function since we're moving to globally unique names for the generated functions anyway. I'm mostly curious.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Does that cause any actual slowdown?

Unclear; would have to measure.

Comment 6

[Till Schneidereit [:till]]

(In reply to Boris Zbarsky [:bz] from comment #5)
> > Does that cause any actual slowdown?
> 
> Unclear; would have to measure.

Ok, sure. I just wanted to make sure I'm not overlooking something in not seeing proof for it in this test case.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, if I modify the testcase to do:

	return new Function(fnbody);

instead of the thing it does now, the time does drop significantly.  But that's because the function bodies are all very short.  If I just make them a bit longer, the time goes back up.  So it depends on what your function bodies look like.