On Sun, 2003-05-25 at 11:49, Zeev Suraski wrote:
> At 17:06 25/05/2003, Sterling Hughes wrote:
> >I'm must be going senile then :) Let zobj be an object zval.
> >zobj->properties and zobj->ce->properties_info is what I'm talking
> >about.
> >
> >When object properties are looked up, via read_property(), first a
> >hashtable access is done on zobj->ce->property_info, to find the
> >property access levels, then the property access levels are verified.
> >Then the lookup is done on zobj->properties to find the property value,
> >and we are all happy.
> >
> >A first time lookup is fine, but per-object this need not be looked up
> >and verified more than once. Therefore, if we change each individual
> >property to contain an extra field, verified, we can save this check
> >each time the object property is accessed. Something like:
> >
> >struct obj_property {
> > zval *value;
> > int verified;
> >};
> >
> >Where the verified state is maintained per-object, we should be able to
> >cut repeated accesses down to nothing. Unless I'm missing something?
>
> I think you're missing a bit :) What does 'verified' mean exactly, that
> someone can access this property? Or do you want to keep a list of
> contexts that are allowed to access it, vs. ones that are not?
>
> What you might be thinking is to copy the property information from the
> class entry into each individual property. That might work and save us a
> lookup, but it would also be a horrible memory (and probably also
> performance) hog to maintain. The problem is that if you go down to
> basics, the property information belongs in the class entry, whereas the
> value of each individual property belongs in the object instances, and thus
> it cannot be in the same place.
>
> One optimization that we could make is keep a pointer from each property
> value to its corresponding property_info entry. The price of that is some
> additional memory overhead, plus the fact that we'd have to give up the
> standard zval sybmol table that objects today have, that can bring about
> quite a few annoying side effects. It won't completely annihilate the
> overhead either - because we'll still have to make the checks, we'd just be
> saving the lookup.
>
Yeah, this was my initial thought, but instead of maintaining a pointer
to property_info, we can just maintain the integer access value. I
really don't care which is done, as they are both 4 bytes.
> I'll try to think of some creative ways to speed things up, but profiling
> it a bit and knowing where we spend the bulk of the time would help.
>
Use cachegrind. Profiling is what lead me to this idea. :)
-Sterling
> Zeev
--
Good judgement comes from experience, and experience comes from
bad judgement.
- Fred Brooks
