Premature optimization is the root of all evil
Donald Knuth.
We’ve all come across this quote, perhaps numerous times. Yet, despite its familiarity, many developers persist in employing outdated techniques.
Why is this, and what’s the issue? Let’s delve into it.
It appears to me that a fondness for “performance tricks” often afflicts developers with a decade or more of experience. They possess a wealth of tricks and harbor thoughts such as “it won’t hurt” and “you can never have too much performance.” Then there are developers who seek to showcase their prowess with statements like, “Check out this neat trick I know.”
The consequence? We end up with code that looks something like this:
Why opt for “sizeof” over “count”? Why not use “foreach”? And what’s with the reliance on “echo”? And why the obsession with isset for string indices?
All these choices were once touted for their supposed “performance” benefits. At least, that’s what we believed a decade ago. But in reality, there was little merit in employing such tactics even back then. Sure, some quirky optimizations might have eked out minuscule performance gains, but:
If you’re fixated on shaving off nanoseconds, you’re wielding the wrong tool (PHP). Chances are, the performance bottleneck in your code doesn’t stem from loop syntax or the choice between double and single quotes. Still not convinced? Consider this: many antiquated tips have lost their relevance entirely.
I’ve singled out five of the most pervasive tricks familiar to any developer who cut their teeth on PHP 5.6 and older. Yet, all of them are obsolete in PHP 8.x+.
- Opting for isset() instead of strlen(). This serves as a prime example of outdated wisdom. Rather than assessing the actual length of a string, we were advised to merely check for the existence of the N-th character in the string.
Indeed, there was a noticeable performance disparity in PHP 5.6. According to my local tests, there was approximately a 40% enhancement.
However, that rationale is no longer applicable post the PHP 7.0 release. String processing underwent significant enhancements, rendering the speed virtually indistinguishable.
Even when tested on a dataset of 500K lines, I couldn’t discern any disparity.
2. Preferring a “For” loop over a “Foreach”. The rationale is straightforward — the “for” loop is acknowledged to be faster than its “foreach” counterpart.
Alright, technically speaking, there’s still merit to the argument. Yes, a “For” loop maintains its speed advantage.
However:
The efficiency of a “Foreach” loop has vastly improved over the years, with significantly reduced overhead. It’s impractical to resort to this optimization unless you’re dealing with arrays containing hundreds of thousands of items. So while this technique does work, it’s unnecessary until you’re faced with the task of iterating through a massive dataset. Otherwise, you’re needlessly sacrificing code readability without a compelling justification.
3. Opting for single quotes over double. The rationale was straightforward: PHP treats single-quoted strings as simple strings and interprets double-quoted strings as templates that can include variables. The principle was simple — reserve double-quoted strings solely for cases involving variable interpolation.
To be frank, even back then, I harbored doubts about this particular trick. Honestly, I couldn’t fathom what kind of codebase would necessitate such a tweak to truly make a difference.
Nowadays, it’s officially rendered obsolete. Thanks to the significant enhancements in string processing introduced in PHP 7.0, string operations are blazingly fast. You’re perfectly fine to employ double quotes liberally. Seriously, spare yourself the trouble of fretting over quote marks.
4. Opting for concatenation over template strings. This notion mirrored the sentiment of the preceding point. Template strings were deemed slower than simple strings, leading developers to favor string concatenation over templates, even if it meant sacrificing aesthetics.
The essence remains unchanged — employing such tactics after PHP 7+ is futile. In fact, a PHP engine contributor has indicated that concatenation may even be slower than string templates in modern PHP.
5. Preferring prefix increment over postfix. Frankly, it seems nonsensical to me. Come on, there’s no plausible scenario where this would yield significant performance gains. Yet, I’ve encountered it far too frequently in actual code to doubt people’s belief in its efficacy.
Granted, there may have been a marginal speed discrepancy a decade ago. However, with the Zend Engine’s continual enhancements, the disparity is now minuscule, barely discernible even with millions of operations (I’d love to see PHP code that genuinely requires millions of incrementations).
In summary, eschew Micro-Optimization Tips in PHP, which sacrifice code readability for illusory performance enhancements. Furthermore, refrain from imparting these tricks to beginners. It’s counterproductive.
Some of these tricks simply don’t deliver, while others may provide a microscopic improvement of minus 0.001 microseconds in script execution. It’s utterly pointless. One overlooked SQL query index could nullify all these “improvements.” Conversely, a well-utilized cache could yield seconds of difference rather than microseconds.
Happy coding🚀
