> how do i see why the method is deopted? for example here:
If you --trace-deopt with --code-comments then in most cases you will
get LIR instruction that deopted in the output (though it is not
always correct). The only reliable way to figure what caused deopt is
run with --print-opt-code and go read assembly around deopt point.
> does that mean i should replace the for in with a for loop that iterates
> over Object.keys?
> > does that mean i should replace the for in with a for loop that iterates
> > over Object.keys?
It means you have an object that's either in dictionary mode, or has
enumerable properties in its prototype chain. Ideally you avoid both of
those cases for objects you want to iterate over.
Is it really a good idea to optimize for a specific version of v8? I mean, something you spend a bit of time hand optimizing could be a completely irrelevant optimization in some upcoming v8 release. It could even be slower.
Or am I wrong? :)
On Oct 11, 2012, at 2:48 AM, Christoph Sturm <m...@christophsturm.com> wrote:
Who's optimizing for a specific version of V8? Avoiding inherently slow
things (such as for-in loops over slow objects, or needless polymorphism,
etc) in your JS code makes a lot of sense regardless of the VM you're
running on.
Sure, some deopts may no longer happen in an upcoming version, but then
again maybe they still will, and maybe you want better performance *now*
rather than possibly at some unspecified date in the future.
On Thu, Oct 11, 2012 at 5:46 PM, Michael Schwartz <myk...@gmail.com> wrote:
> Is it really a good idea to optimize for a specific version of v8? I
> mean, something you spend a bit of time hand optimizing could be a
> completely irrelevant optimization in some upcoming v8 release. It could
> even be slower.
> Or am I wrong? :)
> On Oct 11, 2012, at 2:48 AM, Christoph Sturm <m...@christophsturm.com>
> wrote:
> I'm trying to optimize my node app with --trace-deopt
> how do i see why the method is deopted? for example here:
