More compact memory initialization?

[evanw]

I noticed that the static memory initializer in the generated code uses bytes instead of 32-bit ints. Switching it to use 32-bit ints instead made the code significantly smaller in our case (we lost around 150kb). Is there a reason this isn't done when targeting typed arrays?

[kripken]

When you use --memory-init-file you get a binary file anyhow, which is the recommended route when using large initializers. So the other code path has not been optimized that much. But you are very correct, this would be smaller and in the new compiler probably not that hard to do.

[evanw]

Thanks for the pointer to --memory-init-file. I somehow missed that flag.

[kripken]

Would the 32-bit optimization still interest you? Or not relevant with that flag?

[evanw]

We should be fine with --memory-init-file but it seems to me like it's still worth doing since it's such a big win for such a seemingly simple change. This optimization would still benefit projects that are loaded over file://, for example.

[trevorlinton]

+1

[chadaustin]

+1 (ccing myself on this thread)

[kripken]

What are the reasons for not using a mem init file? Is there an issue with that option?

[trevorlinton]

It's difficult to use multiple files and embedding that within the JS isn't an option unfortunately. Albeit that might be a short term solution for me. Is it significant work to use Uint32?

[chadaustin]

We package up our engine JavaScript file with other JavaScript files and expect it to be delivered "atomically", so it wouldn't be able to go and fetch the mem init file at load time. We also wouldn't know where to load it (everything gets uploaded to the CDN by the hash of its content).

It's way more convenient if we can just have an efficient JavaScript representation of the mem init array. Perhaps a string or base64 string of some sort.

It's not yet a big enough pain point to fund work to submit a pull request, but perhaps this clarifies our use case.

[kripken]

@trevorlinton Not sure what you mean about "multiple files and embedding"? The mem init file should just work normally in all respects, except there is an extra file.

It is probably not too much work to do uint32. Just write some python to scan and rewrite that stuff.

@chadaustin , surely you download lots of binary assets too? Or is the whole filesystem in a single JS file?

[chadaustin]

On Mon, Mar 31, 2014 at 4:46 PM, Alon Zakai notifications@github.comwrote:

@trevorlinton https://github.com/trevorlinton Not sure what you mean
about "multiple files and embedding"? The mem init file should just work
normally in all respects, except there is an extra file.

It is probably not too much work to do uint32. Just write some python to
scan and rewrite that stuff.

@chadaustin https://github.com/chadaustin , surely you download lots of
binary assets too? Or is the whole filesystem in a single JS file?

Ah, we don't embed any files into our program. We stream all of the 3D
content from our asset server.

The static memory initialization is mostly string constants and global
variables.

Reply to this email directly or view it on GitHubhttps://github.com//issues/2188#issuecomment-39155956
.

Chad Austin
Technical Director, IMVU
http://engineering.imvu.com http://www.imvu.com/members/Chad/
http://chadaustin.me

[kripken]

Couldn't you stream the mem init from your asset server? (can't the JS and the mem init be just more assets?)

[chadaustin]

The asset server is only for 3D content, which is independent of the current version of the emscripten-compiled engine. Also, sometimes the engine is loaded within Node.js or shipped to arbitrary other projects as a single JavaScript file. It's also packaged up with closure compiler into other projects at the company, and they may or may not have convenient access to the asset server.

It's just way more convenient to have a single, self-contained JavaScript file with no external dependencies.

[kripken]

Ok, I see.

Meanwhile I cooked up a patch in the i32-mem-init branch. Looks like it works on most stuff but i see test suite failures, help with more testing and figuring out those issues would be very helpful.

00bc108