3 ms·
It occurs to me that, in practical terms, the "steady state" of performance with the increasingly large blobs of JavaScript we find littered throughout the web
by ddevault 7y ago
It occurs to me that, in practical terms, the "steady state" of performance with the increasingly large blobs of JavaScript we find littered throughout the web tends to impact the user more than other JITs. As the user navigates from page to page, the VM is reset, a fresh set of minified blobs is downloaded and JITed, and a core or two is pinned to do so. That translates pretty directly to a hotter phone, less battery life, and a frustrated user. Sure, when your JVM startup is 0.1% of the runtime of your program, it's not as big of a deal, but when it's more like 20% of the time a user spends using the program (their web browser), it's a lot worse, and has slim potential for improvement.
- pizlonator 7y agoJS VMs try to be really good and smart about startup time like when you visit a page for the first time. The main trick is to interpret the short running code. That said, some JITing makes page load faster. But only if the JIT only kicks in for functions that run more than some amount of time and the JIT is very cheap to run.
- ehnto 7y agoIt has been really frustrating watching the frontend-web evolve. Take Jira for example, the platform is written in Java yet all my time is spent waiting for all the widgets to jiggle their way into existence. No matter how fast your server is, if you have to do 10-20 network requests to hydrate your frontend architecture the network time alone is going ruin your perceived performance. Your server could deliver sub 5ms response times, with 50ms Time to First Byte on the initial request, and it would still feel like wobbly molasses. The JVM is the least of their worries.