Are there any performance benefits of the latter compared to the former? When I tested it on my own, the time it took for one of my projects to load already transpiled was much shorter than when it uses babel/register. Apart from start-up time though, I'm not entirely sure what I'd write to benchmark the two fairly. Does anyone know whether the overhead Babel adds is just from babel/register transpiling code as it's running, or is it slow no matter what you do?
You are correct in that it affects startup time (it will drastically, depending on how large your project is). As for actual runtime, it should make exactly 0 difference unless there is a bug in Node itself (which would sadly not likely to be fixed, since it's deprecated).
Related
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.
I am playing aorund with using LESS along with respond.js to streamline the development of a new site. Both LESS and respond are quite simply neat. However, with LESS in IE I have run into many problems.
For starters in IE8 mode my IE10 reported that id did not understand "map". No problems, I wrote up an Array.prototype map extension. Then it said that it did not understand isArray, once again in IE8 mode. Prototype extensions to the rescue again. Now it comes back saying something along the lines of SyntaxError: Invalid operand to 'in': Object expected
I am not in fact aware of what in might be but in any case I cannot keep adding adhoc prototype extenions on the fly in the hope that things will eventually settle down. Either LESS is unusable with IE or else someone here can point me to all the fixes needed to make it work.
Answer for your question:
First of all, LESS client side compilation is supported only in IE9+.
You could probably fix this using shims and polyfills for ES5, like these.
But please, don't.
What you should probably do (and forget the first part):
However, despite of really good caching mechanisms provided by the LESS compiler (eg. using localStorage to preserve generated code) using it i production isn't considered a good practice.
GruntJS and Bower.io work in the console, but are relatively easy to configure. Basically, you set them up once and forget they've ever existed:)
Livereload provides you with a GUI and it's incredibly easy to use.
I used GruntJS for frontend development with backend developers working with PHP (CakePHP, Zend, Laravel) and it made our lives much, much easier :)
It seems much more reasonable to streamline your frontend development workflow using a task runner like GruntJS or Brunch.io or install Livereload. These tools will monitor the file changes and generate a new CSS file on every save (and also, reload your CSS on the fly).
You can install GrunJS with watch and LESS plugins and keep is very simple this way. You could even use LESS Node.js package installed globally to the job.
I'm using the RequireJS Optimizer on a project of mine and, by default, it uses UglifyJS. However, I was encountering an error ('anim' is undefined) when running on IE and Opera. Switching to the Closure Compiler with no other configuration change, just sticking to defaults, makes the problem go away.
How can I get an effective diff of the optimized output these two tools produce?
I don't mean to compare the capabilities of the two, either way is fine with me, but this may help point out a bug in one or the other.
First you'll need to merge each minifier's output to single line in case it adds newlines to avoid some obscure old browser bugs (at least GCC does). Then you can use visual diff utility that highlight changes inside single line between two compared variants. At least meld and winmerge have this functionality. Most other should have it too.
Run both through closure compiler whitespace only mode with pretty printing enabled. This will make it easier to isolate the differences.
I want to ask if someone measured impact of some javascript obfuscators on the resulted code. I am aiming mobile users so the speed is cruicial. And I am especially trying to run 2 or 3 different obfuscators on same code in a row, which obfuscates the code very well, but I am afraid that it will have some speed impact.
it shouldn't. Compiler/interpreters couldn't care less about what your symbols are, as long as they are correct.
Most JavaScript obfuscators only minifies and rename local variables, which is extremely easy to reverse-engineer with a beautifier.
The best combination I've found is the DojoToolkit and the Closure Compiler in Advanced Mode.
Closure in Advanced Mode makes JavaScript code almost impossible to reverse-engineer, even after passing through a beautifier. Once your JavaScript code is obfuscated beyond any recognition and any possibility to reverse-engineer, your HTML won't disclose much of your secrets.
This link for using the Dojo Toolkit with the Closure Compiler in Advanced Mode for mobile applications:
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
The Closure Compiler in Advanced Mode actually makes JavaScript runs faster in mobile environments due to its industrial-scale optimizations. For example, in-lining of functions, virtualization of prototype methods, namespace folding, dead-code removal etc. will all make code run faster, so it is not only an obfuscator, it is an optimizing compiler as well.
My own benchmarks runs code on the iPad around 10-20% faster, and 30% faster on the Android. Memory usage is also reduced.
Your question really needs an analysis on your own javascript in order to arrive at a useful answer.
Often though, obfuscation actually speeds up javascript since the file sizes are reduced (faster loading) and symbols get small names (less to compare against).
If the obfuscator is doing some encoding and calling eval, like some do, then there will be a performance penalty at script load time. After that is run, there should be no difference and, as stated before, it may speedup your code due to slower size.
That depends on what you mean by obfuscation.
If you're referring to minification, using a tool like JSMin, then the effect is nil.
If you're talking about something like Packer, the eval process actually does have an impact on how long it takes for the code to execute. On a slow device, that impact can be significant.
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/