909890 - Outlining makes no dent in compilation time for ammo.js

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Alon Zakai (:azakai)]

Attachment: ammo_builds.zip

Emscripten's outlining reduces function sizes in ammo, but that does not seem to affect compilation time - so it looks like something other than function size might be the problem there.

Attached are several ammo builds. On my machine,

outlining limit   startup   max func lines   total size
     none          680ms        2649           6.40MB
    10000          660ms        1217           6.46MB
     2500          685ms         570           6.83MB
     1000          781ms         436           7.66MB

Outling increases total size, pretty modestly at first though, but in theory that could counter the benefits it brings. However nothing to 2500 (top 3) seem essentially unchanged, so I wonder if something totally different is not the issue here.

Comment 1

[Luke Wagner [:luke]]

This doesn't seem too surprising; it looks like the functions weren't that long to begin with.  Also parallel compilation can pretty well hide outliers; what results do you see for javascript.options.ion.parallel_compilation = false?

Comment 2

[Alon Zakai (:azakai)]

Numbers are all in the shell, so I assume they are without parallel compilation? I don't see a shell option to affect that, although I thought there used to be one. Perhaps this build is not a threads build.

Comment 3

[Alon Zakai (:azakai)]

Got a build with --ion-parallel-compile, with that off, i see the same numbers (so was off before too I assume).

Comment 4

[Luke Wagner [:luke]]

Ok.  Well, this is a useful data point.  Perhaps the 2649-line function doesn't torture Ion algorithms like the other big functions we've been seeing (from a quick look, does it appear to have a simplistic structure?).  It looks like any lower outlining limit than 10,000 is just a bad idea, anyhow (from both a space and throughput perspective).

Is there anything else you think we need to investigate?

Comment 5

[Alon Zakai (:azakai)]

I was hoping we could somehow see how much time Ion spends in the different optimization passes, something like that? The prime factor is not function size of # of variables, perhaps it is something else we can work around?

Comment 6

[Luke Wagner [:luke]]

Perf doesn't show anything too out of the ordinary.  TokenStream::getTokenInternal is a bit higher than normal, though.  Could you compare on a minified builds?

Comment 7

[Alon Zakai (:azakai)]

I tested initially on unminified builds, numbers are the same. I switched to unminified for the attachment here to make line counting etc. easier.

Comment 8

[Luke Wagner [:luke]]

Ok, well, it looks like this will be helped by bug 901109 like most other big codes.  I'm not sure there is anything else to do here, though.