What compiler options are best to ensure that dartdevc generates minifier friendly javascript code which can be compressed by google closure compiler in ADVANCED mode.
Please show a tested example that specifies options for 1. dartdevc, and 2. java -jar goolge-closure-compiler.jar as a simple bash script, without pub.
Module type should be 'common' if possible, dart_sdk.js should be included, the final result should be es3 or es5 for compatibility with all browsers, and all output goes into one compressed .js file.
The dartdevc compiler is not meant for production usage at this time, and does not support any sort of "advanced" optimizations (such as those done by the Google Closure Compiler). Our only supported optimization path is using dart2js, our optimizing compiler which in many cases is as good as or better the Google Closure Compiler.
See "When should I use dartdevc" on our FAQ page:
Use dartdevc whenever you’re actively working on your code.
Keep using dart2js to build your deployed, production application. With dart2js you get advanced optimizations such as tree shaking to minimize downloaded code size.
I'm excited you'd like to see dartdevc work for more use cases, but we are concentrating on a great developer experience and keeping optimization usage in dart2js at this time.
Related
The major JavaScript engines of web browsers and nodeJS have had just-in-time compilers for years.
I was just watching a video on Compiler Explorer showing the assembly code output by many compilers for various CPUs.
This reminded me that I've been curious about the code generated by the JS engines' jits.
Do any of those engines have ways for us to see that low-level generated code?
(If this is out of place on SO please feel free to migrate it to the correct SE site.)
For V8, there is a flag --print-opt-code, which prints generated optimized assembly code for each function that gets optimized. Note that functions only get optimized when they're "hot", not right away, so for a short "hello, world" style program the flag won't print anything. You can make functions "hot" by calling them a lot.
In older versions, there was a --print-code flag for unoptimized code, but since the baseline (non-optimizing) compiler has been replaced by an interpreter, there is no unoptimized code any more. You can print the generated bytecode with --print-bytecode.
If you're using Chrome, you can specify flags to be passed to V8 by wrapping them in --js-flags, e.g. --js-flags="--print-opt-code".
One thing you can always do is interrupt your program while it's running, using a debugger.
If it's spending most of its time in JIT-compiled code, then chances are the current instruction-pointer value (RIP) will be inside some JIT-compiled machine code, which your debugger will disassemble for you. (Or at least the part after the current RIP: x86 machine code uses variable-length instructions, so there's no reliable way to go backwards. You might single-step until you reach a backwards branch to get to the top of a loop.)
But without any way to figure out which function name you're seeing JITed asm for, this is probably not very useful unless you only have one hot loop (e.g. in an artificial test / microbenchmark).
Having the JIT engine print the asm as it generates it (#jmrk's answer) is much more usable; I only mention this technique because it works without any support from the JIT engine, so it can work on anything.
I'm aware of Emscripten and LLVM, but neither are written in JavaScript intended for a browser.
As far as I can tell, the tools exist, but they haven't been put together, but I could very well be missing some key factor that makes it very difficult to compile C++ to JavaScript in a browser.
So I'll mention my naive implementation:
Compile Emscripten to C, then use Clang to compile it to LLVM, then use Emscripten to compile it to JavaScript.
Compile Clang to LLVM, then compile that to JavaScript through Emscripten.
Write some C++ and run it through JavaScript Clang, then run that LLVM through Emscripten to get JavaSscript
Run the resulting JavaScript!
I'm sure I'm missing something from my steps. Please let me know, and let me know if there are any efforts by the community to resolve those missing pieces.
EDIT: JSCPP is the closest I've found, but it lacks a lot of features and frankly the author took on an absurd undertaking, by trying to rewrite the parser etc. on his own, rather than using existing tools. Still, close and pretty neat.
It is possible to compile C++ to JavaScript using a self-hosting version of Emscripten that runs in a browser, such as emception.
Alternatively, it is possible to run a C++ compiler (or even an entire operating system) using an x86 emulator in JavaScript.
I have herd V8 compiles "hot code" optimise javascript performance. Is there any way I can tell what code has been compiled and what code has not?
First and foremost you will need to profile your code in the Profiles tab of the Javascript console in Chrome to see what is worth testing. If a function, module, or whatever you are trying to test does not take up much time, it won't be worth your effort.
V8's JIT is going to make assumptions about your code, if those assumptions are true the code will be lightning fast. If not V8 will deoptimize that code as your program continues. Here is a for instance from my own tests. In the code below I was testing a merge sort function I had written.
console.time('order');
msort(ob);
console.timeEnd('order');
The first run of 60000 random numbers completes after 8ms, and all of the following jump up to around 16ms. Basically the JIT has issues with something I wrote so it recompiled my code. I have seen the exact opposite occur where code jumps to twice as fast. If you want to look at it, this is not the exact version, but one using es6 module syntax.
https://github.com/jamesrhaley/es2015-babel-gulp-jasmine/blob/master/src/js/mergeSort/mergeSort.js
Also if your code was not worth optimizing, then it won't be optimized to begin with. Here is a couple of links that helped me improve my speed when writing js.
https://www.youtube.com/watch?v=UJPdhx5zTaw
https://www.smashingmagazine.com/2012/11/writing-fast-memory-efficient-javascript/#so-how-does-javascript-work-in-v8
If you are willing to build a standalone version of v8, you can just run the shell as follows: d8 --trace-opt foo.js (you might also want to deploy --trace-deopt, since your code might get deoptimized (and then reoptimized again..)).
Another useful option is --print-code which will let you see all the versions of machine code for all the functions which were compiled although this one is probably an overkill. Also there is --print-opt-code.
And lastly use d8 --help to see what other useful options v8 can take.
https://github.com/rogerwang/node-webkit/wiki/How-to-package-and-distribute-your-apps
While packaging my node-webkit app for windows using the steps given in the above link I could not find how to avoid readability of the resulting executable from the merge by archiving software, such as WinZip. EXCERPT(from link above): "The resulting executable from the merge will still be readable by archiving software, such as WinZip."
Is it possible to avoid readability by the archiving apps?
Any help is appreciated!
Fundamentally, running node-webkit is similar to running in a browser, so just as you can't hide your webpage source, you can't truly hide your HTML and CSS in such a way that it can't be read, because it needs to be read by node-webkit at runtime.
The situation is almost the same for Javascript code, with one exception. V8 (the javascript engine in Chrome) provides a "snapshot" capability, which sort of compiles your Javascript into a sort of bytecode that V8 understands. Nwsnapshot is available for node-webkit, which will allow you to avoid shipping your JS code (or at least some of it). However, this option is still experimental, and in fact there is a problem in version 0.8.* of node-webkit (referred to as v8 in the wiki, but not to be confused with the V8 js engine), though it should be working again now in v9. Details can be found here if you're interested:
https://github.com/rogerwang/node-webkit/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Also be aware that it can have performance impacts, if that matters for your application.
You could also make an exe file.
See "Step 2b: Alternative way - Making an executable file out of a .nw file" from the link you provided.
Is it possible to run JavaScript code in parallel in the browser? I'm willing to sacrifice some browser support (IE, Opera, anything else) to gain some edge here.
If you don't have to manipulate the dom, you could use webworkers ... there's a few other restrictions but check it out # http://ejohn.org/blog/web-workers/
Parallel.js of parallel.js.org (see also github source) is a single file JS library that has a nice API for multithreaded processing in JavaScript. It runs both in web browsers and in Node.js.
Perhaps it would be better to recode your JavaScript in something that generally runs faster, rather than trying to speed up the Javascript by going parallel. (I expect you'll find the cost of forking parallel JavaScript activities is pretty high, too, and that may well wipe out any possible parallel gain; this is common problem with parallel programming).
Javascript is interpreted in most browsers IIRC, and it is dynamic on top of it which means it, well, runs slowly.
I'm under the impression you can write Java code and run it under browser plugins. Java is type safe and JIT compiles to machine code. I'd expect that any big computation done in Javascript would run a lot faster in Java. I'm not specifically suggesting Java; any compiled language for which you can get a plug in would do.
As an alternative, Google provides Closure, a JavaScript compiler. It is claimed to be a compiler, but looks like an optimizer to me and I don't know much it "optimizes". But, perhaps you can use that. I'd expect the Closure compiler to be built into Chrome (but I don't know for a fact) and maybe just running Chrome would get your JavaScript compiler "for free".
EDIT: After reading about what about Closure does, as compiler guy I'm not much impressed. It looks like much of the emphasis is on reducing code size which minimizes download time but not necessarily performance. The one good thing they do in function inlining. I doubt that will help as much as switching to a truly compiled langauge.
EDIT2: Apparantly the "Closure" compiler is different than the engine than runs JavaScript in Chrome. I'm told, but don't know this for a fact, that the Chrome engine has a real compiler.
Intel is coming up with an open-source project codenamed River Trail check out http://www.theregister.co.uk/2011/09/17/intel_parallel_javascript/