Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the New V8 Is So Damn Fast

nodesource.com

Post reply on HN
Print view View original

21–30 of 237 posts

Re: Why the New V8 Is So Damn Fast

#21

Post by Avshalom »

gsnedders wrote: post #7
zawerf wrote: post #6

Why can't V8 deduce that the order of keys doesn't matter? It's pretty nuts that just rearranging the keys from { x, y, z } to { y, x, z } would cause a slowdown.

You can't deduce that; you'd need to show that the object is never passed to for..in or Object.keys or similar to be able to avoid storing the insertion order. They could change the representation to not be insertion order dependent, and store insertion order in a separate data structure, but that has its own trade-offs.

Does for..in actually require that keys be returned in a specific order? Most languages specifically call out that the order is not guaranteed (not that that stops developers from relying on an order)

Re: Why the New V8 Is So Damn Fast

#22

Post by thomasfoster96 »

axlee wrote: post #17
sbjs wrote: post #4

Earlier quoted context omitted.

Just use Express.js or Sails.js, they're 1:1 to Sinatra or Rails. Join us!

How is Express even remotely close to Rails? Express is a glorified router.

I think the parent comment was comparing Express to Sinatra and Sails.js to Rails respectively, not altogether.

Re: Why the New V8 Is So Damn Fast

#23

Post by abhorrence »

lovelle wrote: post #15
jerhinesmith wrote: post #3

As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.

I would insanely choose ruby rather than javascript for the major advantages that has to offer. Performance in most of cases is not a real needed over consistency. Also Ruby 2.6 has jit, would be great to see some bench tests. :P

2.6’s JIT is entirely at the method level currently, and unfortunately for certain types of workloads (e.g. Rails) this means the performance benefit is largely outweighed by the call counters and deoptimization checks on every method invocation.

There’s definitely room for improvement, and the inclusion of JIT infrastructure is awesome, it’s just not making much of a performance impact. Yet.

Re: Why the New V8 Is So Damn Fast

#24

Post by iammiles »

axlee wrote: post #17
sbjs wrote: post #4

Earlier quoted context omitted.

Just use Express.js or Sails.js, they're 1:1 to Sinatra or Rails. Join us!

How is Express even remotely close to Rails? Express is a glorified router.

I believe parent's intention was to say that Express is like Sinatra and Sails is like Rails.

To which I agree with the Express / Sinatra similarity.

Re: Why the New V8 Is So Damn Fast

#26

Post by pspeter3 »

I have often wondered if frameworks like React which offer polymorphic methods (eg React.createElement) cause deoptimizations. The common functions also seem to be on the critical path since they will be called 100s-1000s of times per render.

Re: Why the New V8 Is So Damn Fast

#28

Post by windows_tips »

lovelle wrote: post #15
jerhinesmith wrote: post #3

As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.

I would insanely choose ruby rather than javascript for the major advantages that has to offer. Performance in most of cases is not a real needed over consistency. Also Ruby 2.6 has jit, would be great to see some bench tests. :P

Isn't there a Ruby->JS transpiler?

Re: Why the New V8 Is So Damn Fast

#29

Post by stochastic_monk »

wolf550e wrote: post #16
barbegal wrote: post #9

I used to believe that javascript was slow, C was fast and that there was no way to change this because of the way that javascript is interpreted and not compiled. But the more I've learnt about the benefits of "on the fly" / "just in time" optimising compilers, the more I'm convinced this is the future of computing. Being able to use multiple threads and hence multiple cores simultaneously to optimise what is actual…

Welcome to 1995 and the wonderful world of Java. Except in Java you can use threads to use multiprocessing, so you can have efficient shared data structures but also hard to debug bugs.

C++ also does this. A variety of projects, such as MXNet, use JIT compilation. Native compilation gets you far, but there are times where dynamic compilation gets you farther.

Re: Why the New V8 Is So Damn Fast

#30

Post by gsnedders »

Avshalom wrote: post #21
gsnedders wrote: post #7

Earlier quoted context omitted.

You can't deduce that; you'd need to show that the object is never passed to for..in or Object.keys or similar to be able to avoid storing the insertion order. They could change the representation to not be insertion order dependent, and store insertion order in a separate data structure, but that has its own trade-offs.

Does for..in actually require that keys be returned in a specific order? Most languages specifically call out that the order is not guaranteed (not that that stops developers from relying on an order)

The ES spec doesn't require it, but every implementation does insertion order (and insertion order was a deliberate decision by Brendan in the original implementation, IIRC), and the web very much relies on it.

The "new" generation of JS VMs (V8, Chakra, Carakan) all dropped insertion order for array index properties (that is properties whose name is a uint32), but kept it for everything else; that broke about as much as browsers are willing to break, and breaking the general case would be far, far worse.

Post reply on HN