Comments (16)
This optimizes parsing, not execution. Parsing is basically done when script is added to a page. So in general, yes, this boosts only startup, but isn't that a good thing already?
from optimize-js.
I'm fine to change the phrasing to emphasize "parsing." Execution does occur when the script is loaded, but using that phrase makes it sound like every API call is faster, which is not true.
from optimize-js.
@tchock @NekR I wrote a blog post some time ago describing this lazy parsing concept in more details: Lazy Parsing in JavaScript Engines.
Note: pre-parse is V8's specific term. In JavaScriptCore, it's simply called syntax checker.
from optimize-js.
@nolanlawson It'll be good to report the standard deviation of those measurements. Probably easier if you just use Benchmark.js. See also this excellent article from @mathias and @jdalton Bulletproof JavaScript benchmarks
from optimize-js.
Good point. What could I do to make this clearer?
Essentially I run:
var start = performance.now();
// code goes directly here
var end = performance.now();
report(end - start); // this is a global function defined in index.html
Scripts are loaded 251 times (using random query string parameters to ensure the browser re-parses), then the median is taken. Arguably this should be more than 251 to reduce variance, but 251 seemed like a good balance between high variance and waiting a long time.
How would you recommend I amend the README? I'm happy to accept a pull request. :)
from optimize-js.
By "code goes directly here", what does code refer to? Please give an example with a hypothetical micro-library.
from optimize-js.
var start = performance.now();
window.MyModule = {hello: 'world'};
var end = performance.now();
report(end - start);
from optimize-js.
So is it that it only boosts initial execution? Execution during runtime (e.g. async tasks and event invoked code) is not touched by the optimization?
from optimize-js.
Yes, parsing is the major thing that's optimized here. My readme is a bit loosey-goosey about definitions; I could be clearer.
from optimize-js.
Optimize a JavaScript file for faster parsing execution.
Also benchmark on mobile where the parsing execution is very important will be great.
from optimize-js.
Indeed it would be good to clarify real world benefit, as by eye it just looks as micro optimization that doesn't bring any noticeable gain.
I take it boost purely parse time, and doesn't bring any improvements to execution time. Is that right? if so, can documentation provide some real world examples (using popular libraries), on why it's useful?
e.g. let's assume that parse time is 10ms, and execution time is 100ms, then if I read the doc correctly, using this module may (in best scenario) speed up my script from 110ms to 105ms.
I'd say that's nothing valuable, and seeing gain numbers as 57.09%
in doc is very misleading to unwary developers.
from optimize-js.
@medikoo If your parse times is 10ms on mobile, then obviously your don't need this optimization. It's opt-in after all. But thing is, benchmarks shown in readme are done on a good Macbook machine and there parse time numbers already often 50ms. I can clearly see that being 500ms on mobile (requires real benchmarks of course).
Anyway, every ms matters and as it's said in readme -- you shouldn't blindly apply with opt to your project. Test and measure first. If it gives boost, then it makes sense to use this opt.
P.S. But I agree anyway with requirement of clear docs and benchmarks on mobile (otherwise, indeed, you'll have hard time convincing people).
from optimize-js.
Same here! Would suggest something like "Optimize JavaScript to be parsed faster". Beside that I also wonder if it does affect runtime performance at all (i.e. does it change JIT at all)? I would not apply such a pattern until I'm certain that there are no hidden costs once you actually use the functions. It feels like it just postpones some engine steps that would otherwise be applied while parsing (for better JIT'ing?). Overall I agree that doing as much as possible lazy is a good idea, as long as there are no heavy costs involved later. So this seems use case specific and I guess one might see better performance if i.e. only one jQuery function is used. But testing this would certainly need detailed benchmarks; and interpreting the numbers could be quite difficult.
from optimize-js.
@mgreter Kyle wrongly used "JIT" word in this situation. JIT isn't related to lazy parsing, JIT is Just-In-Time compilation to machine code. E.g. for C++ you do that on build step, but for JS browsers do that when they load source code, i.e. Just-In-Time.
from optimize-js.
@NekR I actually wonder if this pattern influences how V8 can do JIT optimizations?
from optimize-js.
Thanks for the links; I'll take a look. The benchmarking here could definitely be more rigorous. I didn't use benchmark.js because I didn't see an easy way to hook it in and do the full re-evaluation (e.g. note how I had to append random query params to ensure code wasn't pre-cached/-JITed).
from optimize-js.
Related Issues (20)
- Benchmark script's improvement calculation is off a bit HOT 4
- Have you tested angularjs v1 and v2? HOT 1
- Use benchmark.js or similar, report standard deviation
- uglify > optimize source map HOT 1
- Not as optimized for Browserify as it could be. HOT 3
- Benchmark unfairly excludes compilation time. HOT 4
- Bad Readme example? HOT 2
- Benchmark doesn't appear to work.
- I made a Web UI for optimize-js
- Is there a browser side version? HOT 2
- Is the readme correct? HOT 1
- Made a Ruby gem
- Do minifiers undo this? HOT 1
- Heuristic improvement: don't paren-wrap lazy-require()d modules
- Encoding problem HOT 2
- Memory leak HOT 3
- Reaches parse error with async functions
- Can you update tests in README to current browser versions? HOT 1
- Unrecognised character '#' on line 1
- Vulnerability GHSA-7FHM-MQM4-2WP7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from optimize-js.