cperl
cperl copied to clipboard
perl11
lazy parsing
from javascript optimizers: parse function bodies only when executed or inspected. keep it as string, webkit even only stores the range in the file, which is mapped. before starting we should check the percentage of dead code, and string vs ops memory costs and parse time per typical body. -c (PL_minus_c) needs to turn it off.
see eg. mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=678037
# scripts created / dead / % totalSize created / dead / %
Startup: 4.5K / 3.6K / 80% 2.0MB / 1.6MB / 79%
GMail: 20K / 15K / 73% 8.7MB / 6.3MB / 73%
Facebook: 9K / 7K / 75% 4.1MB / 3.0MB / 73%
Google: 6.9K / 5.3K / 76% 3.1MB / 2.3MB / 73%
Session: 97K / 72K / 74% 43MB / 30MB / 68%
or https://ariya.io/2012/07/lazy-parsing-in-javascript-engines, http://www.mattzeunert.com/2017/01/30/lazy-javascript-parsing-in-v8.html or https://pointersgonewild.com/about/
How well will this work with strict+warnings?
$ perl -E 'use strict; use warnings; sub a { $x };'
Global symbol "$x" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.
This will be deferred until the sub is called. It will miss a lot of warnings in dead code. I will check how JS does the strict checking
JS doesn't have such strict checking (partly because everything can be global), that's why it can get away with it.
The checks all happen at runtime.
> "use strict"; function a() { x += 1 }
(no error)
> "use strict"; console.log(1); x+=1;
1
ReferenceError: x is not defined
That second one doesn't even have a function surrounding it. It's not about function bodies not bieng parsed.
In general, it's a tradeoff, you lose static checking (which is a big advantage) for your functions for a reduction in memory
ad 1: that's why the 2nd example did find the problem, the first not.
ad 2: You lose static checking at compile-time, but can enforce it via -c or some new switch to turn off lazy parsing. You get all checks at run-time or for BEGIN blocks.
The advantages are not only memory, creating useless code is mostly a performance issue. For ~80% dead code this is a valid tradeoff, that's why javascript did it.
ad 1: that's why the 2nd example find the problem, the first not.
It doesn't. The console.log is executed.
function a() { x += 1 }error inside a body, not executed. silentconsole.log(1);no error, continue.x+=1;error outside a function body: error.
What I'm getting at is that JS doesn't have a Perl-like lexical scope checking, even with "use strict".
Yes, JS is a very primitive language. dart or typescript are the better versions.