Hướng dẫn php 8.2 performance
It’s nice to have performance gains, but at this point is marginal version to version. The ones that haven’t jumped from 5.x are the ones that will see big differences, specially on the language side. Show
I wonder if the next step for PHP performance is to use hardware instructions more often, or optimize the compilation to take advantage of something. Who knows if, in the future, PHP will use AVX or even GPU to leverage some heavy tasks. In the meantime, there is no hurry to jump if your on oldest stable. If release trends hold, we should be roughly half-way through the PHP 8.2 development cycle with the annual feature releases normally out toward the end of November. Given that, this weekend I decided to try out the state of PHP 8.2 Git and carry out some early benchmarks to get an idea where things are headed. PHP 8.2 is introducing support for read-only (readonly) classes, a function for resetting the memory peak usage tracking, sensitive parameter value redaction in stack traces, deprecating of dynamic properties, and various other changes. Some testing over the weekend of PHP 8.2 Git went well and was uneventful. From an AMD Ryzen 9 5950X developer box, I ran some benchmarks seeing how PHP 8.2 Git was comparing to the latest PHP 8.1.6 release on the same system as just some very preliminary benchmarks for this roughly half-way point through the PHP 8.2 cycle. PHPBench was showing a roughly 2.5% increase in the PHP 8.2 performance over PHP 8.1, which isn't as large as seen as in some past releases, but keep in mind we are still far out from the actual PHP 8.2.0 release... And it's on top of the many performance gains already over the PHP 7.x and 8.x series. There were small but measurable improvements in some of my own Phoronix Test Suite performance benchmarks for various PHP CLI tasks. Like the time to generate many SVG graphs continues to improve with PHP 8.2. The peak memory usage on PHP 8.2 Git is also lower than PHP 8.1. So at least from my initial testing, PHP 8.2 continues moving in the right direction of being faster albeit by within a couple percent in the various tests so far and with slightly lower peak memory usage too. Of course, once the PHP 8.2 stable release is approaching I'll be back around with many more benchmarks and going back to comparing the performance to more historical PHP5 and PHP7 releases too. Scout APM helps PHP developers pinpoint N+1 queries, memory leaks & more so you can troubleshoot fast & get back to coding faster. Start your free 14-day trial today. PHP 8.2 will be released on November 24, 2022. In this post, we'll go through all features, performance improvements, changes and deprecations one by one. # Readonly classes RFCReadonly properties were introduced in PHP 8.1. This RFC builds on top of them, and adds syntactic sugar to make all class properties readonly at once. Instead of writing this:
You can now write this:
Functionally, making a class readonly is entirely the same as making every property readonly; but it will also prevent dynamic properties being added on a class:
Note that you can only extend from readonly classes if the child class is readonly as well. PHP has changed quite a lot, and readonly classes are a welcome addition. You can take a look at my video about PHP's evolution if you want to as well: # Deprecate dynamic properties RFCI'd say this is a change for the better, but it will hurt a little bit. Dynamic properties are deprecated in PHP 8.2, and will throw an
Keep in mind that classes implementing
If you want to learn more about why deprecations are useful and how to deal with them, you can read this followup post on how to deal with deprecations, or you can check out my vlog: # New random extension RFCPHP 8.2 adds a new random number generator that fixes a lot of problems with the previous one: it’s more performant, more secure, it’s easier to maintain, and doesn’t rely on global state; eliminating a range of difficult to detect bugs when using PHP’s random functions. There’s a new
class called
# null, true, and false as standalone types RFCPHP 8.2 adds three new types — or something that looks like it. We'll avoid going down the rabbit hole of type safety in this post, but technically
Before PHP 8.2, you could already use
The same now also goes for # Disjunctive Normal Form Types RFCDNF types allow us to combine union and intersection types, following a strict rule: when combining union and intersection types, intersection types must be grouped with brackets. In practice, that looks like this:
In
this case, It's a nice addition, especially since it means that we can now have nullable intersection types, which is probably the most important use case for this feature. # Constants in traits RFCYou can now use constants in traits:
You won't be able to access the constant via the trait's name, either from outside the trait, or from inside it.
You can however access the constant via the class that uses the trait, given that it's public:
# Redact parameters in back traces RFCA common practice in any codebase is to send production errors to a service that keeps track of them, and will notify developers when something goes wrong. This practice often involves sending stack traces over the wire to a third party service. There are case however where those stack traces can include sensitive information such as environment variables, passwords or usernames. PHP 8.2 allows you to mark such "sensitive parameters" with an attribute, so that you don't need to worry about them being listed in your stack traces when something goes wrong. Here's an example from the RFC:
# Fetch properties of enums in const expressions RFCFrom the RFC:
That means that the following code is now valid:
# Return type changes for DateTime::createFromImmutable() and DateTimeImmutable::createFromMutable() breakingPreviously, these methods looked like this:
In PHP 8.2 those method signatures are changed like so:
This change makes a lot more sense, as it improves static insight possibilities for classes extending from # utf8_encode() and utf8_decode() deprecations RFCIn PHP 8.2, using either
The RFC argues that these functions have a inaccurate name that often causes confusion: these functions only convert between The alternative? The RFC suggests using # Locale-insensitive strtolower() and strtoupper() breaking RFCBoth # Signature changes to several SPL methods breakingSeveral methods of SPL classes have been changed to properly enforce their correct type signature:
# New n modifier in PCRE upgradingYou can now use the # ODBC username and password escaping breakingFrom the UPGRADING guide:
The same applies to Noticed a tpyo? You can submit a PR to fix it. If you want to stay up to date about what's happening on this blog, you can follow me on Twitter or subscribe to my newsletter: # Deprecate ${} string interpolation RFCPHP has several ways of embedding variables in strings. This RFC deprecates two ways of doing so, since they are rarely used, and often lead to confusion:
To be clear: the two popular ways of string interpolation still work:
# Deprecate partially supported callables RFCAnother change, although one with a slightly smaller impact, is
that partially supported callables are now deprecated as well. Partially supported callables are callables which can be called using
The reason for doing this? It's a step in the right direction towards being able to use
That's all there is for now, I'll keep this list updated throughout the year. You can subscribe to my newsletter if you want to receive occasional updates! Noticed a tpyo? You can submit a PR to fix it. If you want to stay up to date about what's happening on this blog, you can follow me on Twitter or subscribe to my newsletter: FootnotesDealing with deprecations The evolution of PHP Deprecated dynamic properties in PHP 8.2 What's new in PHP 8.1 What's new in PHP 8 What's new in PHP 7.4 |