5 ms·

What are you suggesting "compile those statically using full optimization" would mean in this context? The point of the article is that v8's optimizations work

What are you suggesting "compile those statically using full optimization" would mean in this context? The point of the article is that v8's optimizations work by watching the code execute. It can inline functions because it saw where they got called from; it can turn property accesses into fixed-offset lookups because it saw what object the accesses happened to, and so on. (Unless you're talking about asm.js-style optimizations, but then the answer is presumably to use asm.js...)

dfox 9y ago
Most of what jQuery does could be moved into standard browser APIs and then presumably implemented in native code. I feel that implementing it that way would certainly be significantly faster, because any performance loss from impossibility of trace-directed optimizations is outweighted by significant reduction of amount of crossings between native and JS code with completely different memory model. The fact that VM/native transition is expensive is exactly the reason why things like WebAssembly cannot directly manipulate DOM. But this could not be implemented by writing C++ class that gets exported to JS code as $ when something that looks like jquery is loaded. In JS you can load jQuery and then monkey patch it, which will break when you use this kind of "transparent" optimization.
- robin_reala 9y ago
  Most of what jQuery does could be moved into standard browser APIs and then presumably implemented in native code. It pretty much has been. CSS syntax for selection lead to querySelectorAll, simpler AJAX calls to fetch, DOM manipulation functions were ported into the DOM spec wholesale.
cm2187 9y ago
I don't understand well enough dynamic language compilations to answer that but in principle, having 1 billion devices consuming CPU cycles to JIT recompile the same javascript paths over and over seems horribly wasteful.
- chrisseaton 9y ago
  > recompile the same javascript paths over and over The person you are replying to's point is that they aren't the same paths, when you take into account the other code and data in the rest of the application, which effects how the code even in the shared libraries is compiled.
  - cm2187 9y ago
    They are mostly the same path, like if I select something based on an ID to add a function as an event handler, it is the same path, just with a different argument. I don't know, I am outside of my area of confidence here. But in a world where the technological advances in computing have less to do with increasing computing capacity than reducing power consumption, whether on mobile, laptops or servers, the jquery library that needs recompiling on every execution feels like the non-recyclable plastic bag of computing.
    - chrisseaton 9y ago
      > like if I select something based on an ID to add a function as an event handler Nah it's more complicated than that in reality (I work on dynamic languages and have a PhD in them). You just want to select based on an ID, but in order to make that operator fast, JavaScript would normally pass information about what you want to select, what possible values it could have, whether it's allocated on the heap or you somehow stored it somewhere else, and a whole host of other things. You could say 'well don't do those optimisations then' but then you just have slow unoptimised code and the point was to make this fast.

dfox 9y ago

Most of what jQuery does could be moved into standard browser APIs and then presumably implemented in native code. I feel that implementing it that way would certainly be significantly faster, because any performance loss from impossibility of trace-directed optimizations is outweighted by significant reduction of amount of crossings between native and JS code with completely different memory model. The fact that VM/native transition is expensive is exactly the reason why things like WebAssembly cannot directly manipulate DOM. But this could not be implemented by writing C++ class that gets exported to JS code as $ when something that looks like jquery is loaded. In JS you can load jQuery and then monkey patch it, which will break when you use this kind of "transparent" optimization.

robin_reala 9y ago
Most of what jQuery does could be moved into standard browser APIs and then presumably implemented in native code. It pretty much has been. CSS syntax for selection lead to querySelectorAll, simpler AJAX calls to fetch, DOM manipulation functions were ported into the DOM spec wholesale.

cm2187 9y ago

I don't understand well enough dynamic language compilations to answer that but in principle, having 1 billion devices consuming CPU cycles to JIT recompile the same javascript paths over and over seems horribly wasteful.

chrisseaton 9y ago
> recompile the same javascript paths over and over The person you are replying to's point is that they aren't the same paths, when you take into account the other code and data in the rest of the application, which effects how the code even in the shared libraries is compiled.
- cm2187 9y ago
  They are mostly the same path, like if I select something based on an ID to add a function as an event handler, it is the same path, just with a different argument. I don't know, I am outside of my area of confidence here. But in a world where the technological advances in computing have less to do with increasing computing capacity than reducing power consumption, whether on mobile, laptops or servers, the jquery library that needs recompiling on every execution feels like the non-recyclable plastic bag of computing.
  - chrisseaton 9y ago
    > like if I select something based on an ID to add a function as an event handler Nah it's more complicated than that in reality (I work on dynamic languages and have a PhD in them). You just want to select based on an ID, but in order to make that operator fast, JavaScript would normally pass information about what you want to select, what possible values it could have, whether it's allocated on the heap or you somehow stored it somewhere else, and a whole host of other things. You could say 'well don't do those optimisations then' but then you just have slow unoptimised code and the point was to make this fast.