Page 1 of 1
Getters and Setters versus Performance
Posted: Sat Feb 10, 2007 3:35 pm
by Ambush Commander
If a several pieces of data is going to be accessed a lot, in a loop, is it worth the performance gain to have the client grab the data directly from the property rather than go through an entire function call using a getter?
I think so, but I'm also starting to feel the pain of maintaining backwards-compatibility. It's difficult to keep deprecated properties functional (you'd have to replicate the data in different formats), while getter methods can be converted into facades for the new interface. I can do a global replacement on code that directly access properties that's under my control, but I risk breaking something for other developers who have modified my code.
I was thinking a possibility was to set up getters and setters for unofficial code, and then have a "secret" interface of direct access for my internals for speed reasons. An end-user would usually use the getters and setters, but could use the secret interface at their own peril.
Any thoughts on the subject?
Posted: Sat Feb 10, 2007 4:08 pm
by feyd
I tend to use the __get() magic method for all my accessors (except for the ones that require more than basic processing.) When users are concerned about the performance, I recommend they store the data instead of calling the functions repeatedly.
Re: Getters and Setters versus Performance
Posted: Sat Feb 10, 2007 4:09 pm
by nickvd
Ambush Commander wrote:...but I risk breaking something for other developers who have modified my code.
My thoughts would be... so?
They modified your code, they have to be aware of the potential consequences... You don't see phpbb bending over backwards to support mods that directly modify the core code...
It boils down to one rule in my opinion. If you modify the core code of the application/library, you WILL cause all future upgrades to be quite a bit more painful.
Re: Getters and Setters versus Performance
Posted: Sat Feb 10, 2007 4:15 pm
by timvw
Ambush Commander wrote:If a several pieces of data is going to be accessed a lot, in a loop, is it worth the performance gain to have the client grab the data directly from the property rather than go through an entire function call using a getter?
I believe many people would define a property as syntactical sugar for getX and setX methods.. So i'm presuming you're talking about a class variable?
Ambush Commander wrote:
I think so, but I'm also starting to feel the pain of maintaining backwards-compatibility. It's difficult to keep deprecated properties functional (you'd have to replicate the data in different formats), while getter methods can be converted into facades for the new interface. I can do a global replacement on code that directly access properties that's under my control, but I risk breaking something for other developers who have modified my code.
Ok, this more or less seems to confirm you're talking about a class variable (field) when you say 'property'
- First step to do is mark the property as deprecated (that way you can kick it out in a release or two

)
- Second step to do is remove the public variable and implement the facade using the magic __get/__set functions (this way it will appear as if the variable still exists and you keep backwards compatibility).
Ambush Commander wrote:
I was thinking a possibility was to set up getters and setters for unofficial code, and then have a "secret" interface of direct access for my internals for speed reasons. An end-user would usually use the getters and setters, but could use the secret interface at their own peril.
I don't think it's a good idea to give your own code more privileges because it results in the same problems as you mentionned above... (and source code doesn't have secrets anyway...)
Posted: Sat Feb 10, 2007 4:15 pm
by Christopher
I see no reason why not to let users have direct access to the properties. The only thing that getter/setters give you is the ability to wrap the access with code if necessary -- but __get/__set give you the ability to add that later if you wish.
Posted: Sat Feb 10, 2007 4:18 pm
by timvw
I'm not quire sure if i already shared this thought.. But for a long time i had been wondering what the use of properties was.. Since they're only (seemed to be) syntactical sugar for setX and getX methods... The usefulness of properties is the fact you can silently replace class variables and upgrade them to functions.
Posted: Sat Feb 10, 2007 4:25 pm
by Ambush Commander
Quick note, this is PHP 4, so using __get/__set to simulate is not workable. And yes, we're talking about class variables. Sorry about not being clear about that.
...but I risk breaking something for other developers who have modified my code.
Sorry. I mean developers who used public, but very internal, APIs.

I have no mercy for users who patch my code.
I don't think it's a good idea to give your own code more privileges because it results in the same problems as you mentionned above... (and source code doesn't have secrets anyway...)
But thing is if it's my code, I can make some global changes and restructuring to make things work better. Not happy with a method name? Rename and do a file-wide string replace! But a property name, hmmm...
Okay. It's seems like asking users to cache the data locally would be a good idea. In fact, it happens to a certain extent in my own code, so I don't end up with things like:
Code: Select all
$definition->info[$token->name]->attr[$attr_key]->validate(...);
Which brings in another monkey-wrench: these are not "simple" class variables. That's a fairly normal call, which will occur hundreds of times, with varying $token->name and $attr_key values. Even if I did cache the accessor's return value, I'd end up calling it several times on different iterations of the loop. If I try to fix up I'd end up building a mirror image of the data-structure and interface directly off of that (which might not be a bad idea. The object is not outrageously large).