Yeah, I was concerned about getting slower results with --closure 2, but I thought I'd try it and see.
Anyway, using NO_FILESYSTEM is a big win, and I'm still in the stage of making a demo, so not in a big hurry to get the size down. Thanks. On Friday, June 26, 2015 at 2:28:07 PM UTC-4, Alon Zakai wrote: > > Closure 2 requires that everything accessed from outside closure code is > exported. If you aren't trying to access something new that you added, then > it sounds like you are hitting a bug where we should export something but > don't. > > We don't normally recommend using closure compiler, because in mode 2 it > makes code slower, so this compilation mode is less tested than others. > > > On Thu, Jun 25, 2015 at 7:26 PM, Alan deLespinasse <[email protected] > <javascript:>> wrote: > >> Thanks. NO_FILESYSTEM is a big help; it reduces the output by about 34k. >> >> NO_BROWSER doesn't seem to work, at least with the other options I'm >> using. When I call the Module function generated by MODULARIZE, it throws >> an error: "Uncaught ReferenceError: Browser is not defined". So it's >> removing Browser, but not something else that depends on it. This may not >> be a good option for C/C++ functions that are to be called from other >> JavaScript. >> >> I'm still not clear on what --closure 2 requires. Do I need to create a >> JavaScript externs file and somehow pass that to the Closure compiler? I >> would have thought that the EXPORTED_FUNCTIONS setting in Emscripten would >> take care of that. Or maybe there needs to be some other JS file specified >> with --pre-js or --post-js? >> >> >> On Wednesday, June 24, 2015 at 8:06:57 PM UTC-4, Alon Zakai wrote: >>> >>> For --closure 2, the main issue is closure advanced requires special >>> handing of externs, see >>> https://developers.google.com/closure/compiler/docs/api-tutorial3 >>> >>> See the NO_FILESYSTEM and NO_BROWSER options for reducing code size >>> further. >>> >>> We could add an option to only include code that is explicitly in >>> EXPORTED_FUNCTIONS, even runtime support. That would take some work though. >>> But it would be great if it were contributed. >>> >>> >>> >>> On Wed, Jun 24, 2015 at 11:27 AM, Alan deLespinasse <[email protected] >>> > wrote: >>> >>>> I'm trying to compile a fairly straightforward C library into >>>> JavaScript so I can use it in Web applications. I've got it working, but I >>>> think it's larger than it should be. >>>> >>>> The library is basically math functions. I just want to call them and >>>> get their results. They don't do I/O or anything. >>>> >>>> As an example, I'll use the int_sqrt function example from the >>>> documentation >>>> <http://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-compiled-c-functions-from-javascript-using-ccall-cwrap> >>>> : >>>> >>>> >>>> int int_sqrt(int x) { >>>> return sqrt(x); >>>> } >>>> >>>> >>>> Compiling this with -O3 results in an a.out.js file of 143k bytes. I >>>> had thought that -O3 would automatically run the Closure Compiler to do >>>> some minification (vaguely implied by the statement that --closure 0 is >>>> the >>>> "default in -O2 and below >>>> <http://kripken.github.io/emscripten-site/docs/tools_reference/emcc.html#emcc-closure>"), >>>> >>>> but this doesn't seem to be the case. >>>> >>>> After a bit more research, I settled on this command line: >>>> >>>> emcc -O3 hello_function.cpp --closure 1 -s >>>> EXPORTED_FUNCTIONS="['_int_sqrt']" -s MODULARIZE=1 >>>> >>>> This gets it down to 80k, a huge improvement, but still rather large >>>> for such a tiny input. I tried --closure 2, but (a) that only gets it down >>>> to 77k, and (b) then the code no longer works. I get "Uncaught TypeError: >>>> Kc is not a function" in the console when I try to call it from JavaScript. >>>> >>>> I've seen vague suggestions in various docs that --closure 2 would >>>> "require modifications to the source". I think there may have been >>>> something about requiring Closure type annotations. But that doesn't make >>>> sense to me, since the source code I'm dealing with is C. >>>> >>>> So what's actually needed for --closure 2? >>>> >>>> Also, looking at the generated code, there seems to be a lot of >>>> unnecessary stuff, even with --closure 2. For example, I see standard >>>> library stuff like malloc, free, memset, memcpy, etc. It's true that I >>>> might want to call those functions from my JavaScript code (in fact, for >>>> the actual library I'm trying to use, I do need at least malloc and free), >>>> but I thought I would need to declare such things in the >>>> EXPORTED_FUNCTIONS >>>> variable. >>>> >>>> Basically what I'm asking is, is it possible to get the compiled code >>>> much smaller? >>>> >>>> If the answer is "that would require more optimization in Emscripten, >>>> which we haven't had time to implement yet", then I'm curious what it >>>> would >>>> take. I might consider contributing. (I'm pretty experienced with >>>> JavaScript, though new to Emscripten.) >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
