PHP 8.4 Property Hooks: Can we get rid of getters/setters now? A benchmark.

The upcoming PHP 8.4 release will include the brand-new feature “property hooks”, a mechanism to add logic to a class property when read from or written to. One benefit of this feature is that you do not need to protect property access with a private property and public getter/setter methods anymore.

You can find out how this feature works in the RFC and other places, but in the spirit of this blog we want to focus solely on the performance implications.

We would like to know if there is a noticeable effect on performance when we design applications from scratch with public properties backed by hooks and without getters/setters? 

Or, more drastically, is it a winning strategy to leave the getters/setters behind, never look back, maybe even rewrite our existing applications?

From a macro-perspective, the answer is no.

Looking at a call graph for our own Transaction settings list view, we see that even when rendering a large amount of 100 Doctrine entities, calls to their getters account for a minimal amount of time in the request, fractions of milliseconds.

Changing the code to use public properties and property hooks will not significantly alter the application performance.

Nevertheless, it’s interesting to dive into a benchmark of property hooks vs. getter/setters, to understand if both approaches have a similar performance. If they do, it is unnecessary to consider performance, when deciding between the two. And that reduces mental load.

Establishing Baseline: Public Property vs Getter/Setter

It’s a well-known fact that public property access is faster than going through a getter method to access a private property. We can set up a benchmark with hyperfine to calculate that difference to be roughly 60% slower for getters/setters with these code examples:

Public Properties are rarely used, despite their speed, due to the importance of other concerns:

1. Information Hiding: Using getters/setters allows us to avoid exposing how the data is stored in the class.
2. Changing a public property to a getter in the future requires numerous refactorings, or the use of magic __get methods, Both of these are unnecessary risks that can be avoided by using getter/setter methods from the start.

With property hooks, both concerns can be addressed by adding property hooks, when the access to the public property should be restricted in any way.

Comparing Public Property with Hook vs. Getter

So, let’s add a property hook example for reading and writing that resembles the logic of the getter and setter methods.

Both approaches are very close to each other with only a 9% performance difference.

So the result is clear: Performance should not be a concern when you decide to use either properties with hooks or getter/setter methods for accessing properties on classes. This is especially true because, as we saw at the beginning, property access usually accounts for only a small part of the total request time.

The case for benchmarking: Hook performance improvements during PHP 8.4 alpha

While it is important to know that both approaches have similar performance characteristics, micro-benchmarking new features vs. old alternatives serves another purpose. 

We wanted to write this blog post directly after property hooks were merged because from our experience we expected the conclusion to be that performance is not a concern.

But when we ran the numbers with an early PHP 8.4 alpha, we realized that property hooks were about 200% slower than getters. 

Turns out, the implementation of property hooks was not optimal, and we reported this behavior to the property hook feature authors Ilija and Larry. The fix required another amending RFC, but was approved by PHP RFC voters, leading us to the performance we have now during the PHP 8.4 release candidate phase.

Related Posts

• How we use hyperfine to measure PHP Engine performance
• New in PHP 8.4: engine optimization of sprintf() to string interpolation