Ok, this means I have a shot at having my code compiled monomorphically by
creating my objects without prototype, which I don't need anyway because
such information is useless to me as it's not stored in JSON/BSON.
How about these two objects. would they share the same hidden map?
var o1 = {};
o1.x = 1;
var o2 = {x:1};
Thanks!
On Monday, July 23, 2012 11:53:20 AM UTC-3, Vyacheslav Egorov wrote:
>
> Yes.
> --
> Vyacheslav Egorov
>
>
> On Mon, Jul 23, 2012 at 4:48 PM, Sebastian Ferreyra Pons
> <[email protected]> wrote:
> >> Yes. In a constructor function, the hidden class begins with an
> >> element that also includes a prototype. In two different constructor
> >> functions these initial elements will be different, making their
> >> hidden classes different.
> >
> > Does this mean that if I make sure that both the mongo driver and my
> code
> > uses the literal empty object {} for creating new objects they will
> share
> > the same root class?
> >
> > On Friday, July 20, 2012 2:21:39 AM UTC-3, jMerliN wrote:
> >>
> >> Hi Sebastian,
> >>
> >> > It is my understanding that hidden classes are not shared between
> >> > different
> >> > constructors, even if I construct structurally identical objects with
> >> > the
> >> > same properties and in the same order. This seems to imply that
> >> > deserialized objects coming from mongodb will not share the same
> hidden
> >> > class as structurally identical objects created by the constructors,
> >> > hence
> >> > functions that use these objects will not be well optimized into
> native
> >> > code. Am I right?
> >>
> >> Yes. In a constructor function, the hidden class begins with an
> >> element that also includes a prototype. In two different constructor
> >> functions these initial elements will be different, making their
> >> hidden classes different.
> >>
> >> If you have hot code that is being impacted because you pass it both
> >> objects you construct and ones from the MongoDB driver you're using,
> >> one thing you can do is make your constructor take the MongoDB object
> >> representation as an input. Then you would be able to make your hot
> >> code monomorphic. If you don't have any hot code being impacted, it's
> >> probably not something you should worry about unless your Mongo driver
> >> is putting objects it constructs into dictionary mode for some reason.
> >>
> >> An example: http://jsfiddle.net/xznxP/
> >>
> >> "hot" only deoptimizes when given the raw object here, which has a
> >> different hidden class.
> >>
> >> > Is there any hidden class inheritance built into v8? That is, if I
> >> > create
> >> > object o={a:1, b:2} and later add o.z=3, will native code optimized
> for
> >> > the
> >> > hidden class before the property-add still work unmodified
> afterwards?
> >>
> >> No.
> >>
> >> - Justin
> >>
> >> On Jul 19, 4:16 pm, Sebastian Ferreyra Pons <[email protected]>
> >> wrote:
> >> > I have two questions.
> >> >
> >> > #1
> >> > I'm developing a Node.js/Mongodb web app.
> >> >
> >> > This means that objects used in the code will be created by at least
> two
> >> > different code paths:
> >> >
> >> > 1. Constructor functions
> >> > 2. Deserialization code in the mongo driver.
> >> >
> >> > It is my understanding that hidden classes are not shared between
> >> > different
> >> > constructors, even if I construct structurally identical objects with
> >> > the
> >> > same properties and in the same order. This seems to imply that
> >> > deserialized objects coming from mongodb will not share the same
> hidden
> >> > class as structurally identical objects created by the constructors,
> >> > hence
> >> > functions that use these objects will not be well optimized into
> native
> >> > code. Am I right?
> >> >
> >> > #2
> >> > Is there any hidden class inheritance built into v8? That is, if I
> >> > create
> >> > object o={a:1, b:2} and later add o.z=3, will native code optimized
> for
> >> > the
> >> > hidden class before the property-add still work unmodified
> afterwards?
> >
> > --
> > v8-users mailing list
> > [email protected]
> > http://groups.google.com/group/v8-users
>
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
