On Monday, January 9, 2017 at 7:27:06 AM UTC-6, Floh wrote: > > PS: I guess I misread your reply, you're using a bytecode VM in the code, > not compiling in a VM (or may be you do in that case shared directory perf > might be the main problem). > > dunno.
the directory I am including into the built program has ~ 70 files, and is about 80MB, producing an 80MB ".data" file. had initially tried a directory with ~ 500MB and 300 files, but emcc is not happy and complains, so I made a more minimal asset directory. most of the space/files is due to voxel terrain, and some due to scripts and similar. as for the script VM, it compilers to bytecode as an intermediate step, but typically loads scripts from source. typically, for execution, the bytecode is either converted into a call-threaded form, or JIT compiled to native (x86 and x86-64 only). potentially, the VM could be either made to use precompiled bytecode images, or the scripts could potentially be moved into the engines' VFS, if needed. Anyway, I timed my own 110k emulator code base on OSX (mid-2014 MBP with > SSD, 2.8 GHz i5 CPU) > > my program is 200k lines, OS is Windows 10, with the drive on a 7200 RPM HDD. CPU is a 4.2 GHz AMD FX 8350 (with DDR3-1600 / PC3-12800 RAM). > - native compile, clang with ninja: 27.6 seconds > - emscripten compile with ninja: 48.21 seconds > > All in release-mode with -O3, the emscripten version also uses > link-time-code-generation (which increases linker time), the native version > doesn't use LTCG. But I think the main chunk goes into the emscripten > process of converting LLVM bitcode to asm.js. > > clang: not measured exactly, but goes fairly quickly (~ 30 seconds or so). compiling to HTML, normal project build, ~10 minutes. was actually slower before (early on saw closer to 30), but got a little faster for whatever reason (so, now I am seeing closer to 10). build is actually a big unitary / single-compilation-unit build (*1, for the main engine). done mostly as IME unitary builds tend to be a bit faster than compiling files individually and then linking them (I started doing this a bit more with projects after working on the RasPi, as compile times on the RasPi weren't really all that fast, and unit builds helped a fair bit). *1: basically, a single top-level file #include's all the others it needs. if I remove the "--preload-file" line: main program takes approx 2 minutes, whole build (including a few tools/sub-programs) takes approx 5 minutes. testing "make -j 4": full project build time reduced to around 2 minutes. testing MSVC build with "make -j 4", 12 seconds (I generally do MSVC builds via the MinGW build of GNU Make). > Hope this helps a bit to find the culprit for your slow compile times :) > -Floh. > > > Am Montag, 9. Januar 2017 14:13:32 UTC+1 schrieb Floh: >> >> * compiling takes a fairly long time if compared with native compilers, >>> such as MSVC or GCC. >>> >>> Note that if your compiling in a VM (as I think read below in one of >> your replies), and the source code is in a shared directory (shared with >> the host filesystem), then this will be *extremely slow* (at least in >> VirtualBox which I'm using). >> >> What I'm doing is to first rsync the source code into the local VM's >> filesystem, and than compile, preferably through ninja which shaves off a >> couple more seconds and automatically distributes work over available CPU >> cores. With this the entire compile including linking is easily faster than >> a native VStudio compile, but slower than a native clang compile because of >> emscripten's final code generation stage. YMMV of course (depending on how >> big your code base is). >> >> Cheers, >> -Floh. >> >> >> >> >> -- 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.
