Re: Re: Property access slowness
| From: | Zeev Suraski | Date: | Sun, 25 May 2003 15:49:49 +0000 |
| Subject: | Re: Re: Property access slowness | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1989@lists.php.net to get a copy of this message | ||
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.
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.
Zeev