Re: Re: Property access slowness

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