News for hackers. Stuff that matters.
Re:A New Bytecode Format for JavaScriptCore by ksec on Friday June 21, 2019 @03:44PM (#20245730)
And it is already shipped in Safari 12.1 ( Which means many are already using it )

Time and Time again it seems WebKit are the only team that wants to make the Web with better Web Pages with javascript , All the others seems to want the Web to be Fat Apps.

In the hope of anyone in Safari team is reading it.

Please make the Tab Overview Cache the Thumbnail or in List format, currently pressing Tab Overview will reload all the tabs in the background. I don't know if this is for generating thumbnails or other reason. Something that kills my machine when I have 300 Tabs, most of them are "cold" and not loaded.

Re:A New Bytecode Format for JavaScriptCore by randall on Friday June 21, 2019 @03:51PM (#20245781)
...

"The new bytecode format uses approximately 50% less memory, which means a reduction of 10% in overall memory usage for JavaScript-heavy websites, such as Facebook or Reddit."

This is squarely to help webapps be faster and more memory efficient. This change is great, and doesn't align with the cargo cult of, "Make web pages great again."

Re:A New Bytecode Format for JavaScriptCore by saagarjha on Friday June 21, 2019 @03:47PM (#20245751)
> Time and Time again it seems WebKit are the only team that wants to make the Web with better Web Pages ( And we are far from perfecting it ), All the others seems to want the Web to be Apps.

I don’t see how this blog post supports that view, since it’s talking about optimizing JavaScript.

Re:A New Bytecode Format for JavaScriptCore by ksec on Friday June 21, 2019 @04:24PM (#20246022)
By Web page I mean including minimal Javascript, such as making initial JS loading faster, lower latency, lower memory, and in general much better UX. To me Chrome seems to be optimising for the wrong thing, like maximum throughput, WASM, Super fast in Compute intensive usage but eating memory like crazy.
Re:A New Bytecode Format for JavaScriptCore by dchest on Friday June 21, 2019 @05:48PM (#20246566)
https://v8.dev/blog/ignition-interpreter

"V8 team has built a new JavaScript interpreter, called Ignition, which can replace V8’s baseline compiler, executing code with less memory overhead and paving the way for a simpler script execution pipeline."

https://v8.dev/blog/preparser

"Lazy parsing speeds up startup and reduces memory overhead of applications that ship more code than they need."

https://v8.dev/blog/embedded-builtins

"V8 built-in functions (builtins) consume memory in every instance of V8. The builtin count, average size, and the number of V8 instances per Chrome browser tab have been growing significantly. This blog post describes how we reduced the median V8 heap size per website by 19% over the past year."

https://v8.dev/blog/improved-code-caching

"V8 uses code caching to cache the generated code for frequently-used scripts. Starting with Chrome 66, we are caching more code by generating the cache after top-level execution. This leads to a 20-40% reduction in parse and compilation time during the initial load."

Etc, etc.