# Inheritance Cache - Thread: https://externals.io/message/113091 - Original archive: https://news-web.php.net/php.internals/113091 - Started by Dmitry Stogov on 2021-02-05T14:03:12+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #113091 — Dmitry Stogov — 2021-02-05T14:03:12+00:00 URL: https://externals.io/message/113091#113091 Hi, I'm glad to present the result of my recent work - Inheritance Cache. https://github.com/php/php-src/pull/6627 This is a new transparent technology that eliminates overhead of PHP class inheritance. PHP classes are compiled and cached (by opcahce) separately, however their "linking" was done at run-time - on each request. The process of "linking" may involve a number of compatibility checks and borrowing methods/properties/constants form parent and traits. This takes significant time, but the result is the same on each request. Inheritance Cache performs "linking" for unique set of all the depending classes (parent, interfaces, traits, property types, method types involved into compatibility checks) once and stores result in opcache shared memory. As a part of the this patch, I removed limitations for immutable classes (unresolved constants, typed properties and covariant type checks). So now all classes stored in opcache are "immutable". They may be lazily loaded into process memory, if necessary, but this usually occurs just once (on first linking). The patch shows 8% improvement on Symphony "Hello World" app. I'm going to merge this patch into master on next week. Please review and give your comments. Thanks. Dmitry. --- ## #113092 — Benjamin Morel — 2021-02-05T14:22:53+00:00 URL: https://externals.io/message/113091#113092 · In reply to: #113091 > Hi, > > I'm glad to present the result of my recent work - Inheritance Cache. > > https://github.com/php/php-src/pull/6627 > > This is a new transparent technology that eliminates overhead of PHP class > inheritance. > > PHP classes are compiled and cached (by opcahce) separately, however their > "linking" was done at run-time - on each request. The process of "linking" > may involve a number of compatibility checks and borrowing > methods/properties/constants form parent and traits. This takes significant > time, but the result is the same on each request. > > Inheritance Cache performs "linking" for unique set of all the depending > classes (parent, interfaces, traits, property types, method types involved > into compatibility checks) once and stores result in opcache shared memory. > As a part of the this patch, I removed limitations for immutable classes > (unresolved constants, typed properties and covariant type checks). So now > all classes stored in opcache are "immutable". They may be lazily loaded > into process memory, if necessary, but this usually occurs just once (on > first linking). > > The patch shows 8% improvement on Symphony "Hello World" app. > > I'm going to merge this patch into master on next week. > Please review and give your comments. > > Thanks. Dmitry. > Hi Dmitry, that sounds awesome, congrats for this work! If I understand correctly, this only offers performance improvements when the classes are not preloaded, and thus closes a bit the gap between preloading on & off? — Benjamin --- ## #113123 — Brent Roose — 2021-02-09T05:40:32+00:00 URL: https://externals.io/message/113091#113123 · In reply to: #113091 Hey Dmitry Out of curiousity: how does this compare to preloading? From what I understand preloading also links classes, which was one of the most important differences between preloading files and simply storing them in opcache. Does this change mean that preloading becomes much less relevant since class linking can now also happen at runtime? Kind regards Brent > > > Hi, > > I'm glad to present the result of my recent work - Inheritance Cache. > > https://github.com/php/php-src/pull/6627 > > This is a new transparent technology that eliminates overhead of PHP class > inheritance. > > PHP classes are compiled and cached (by opcahce) separately, however their > "linking" was done at run-time - on each request. The process of "linking" > may involve a number of compatibility checks and borrowing > methods/properties/constants form parent and traits. This takes significant > time, but the result is the same on each request. > > Inheritance Cache performs "linking" for unique set of all the depending > classes (parent, interfaces, traits, property types, method types involved > into compatibility checks) once and stores result in opcache shared memory. > As a part of the this patch, I removed limitations for immutable classes > (unresolved constants, typed properties and covariant type checks). So now > all classes stored in opcache are "immutable". They may be lazily loaded > into process memory, if necessary, but this usually occurs just once (on > first linking). > > The patch shows 8% improvement on Symphony "Hello World" app. > > I'm going to merge this patch into master on next week. > Please review and give your comments. > > Thanks. Dmitry. --- ## #113124 — Dmitry Stogov — 2021-02-09T07:21:39+00:00 URL: https://externals.io/message/113091#113124 · In reply to: #113123 Hi Brent, Preloading had intention to completely eliminate opcache overhead, but because of limitations it wasn't able to preload classes with unresolved constants, typed properties and covariant checks. This PR makes these preloading limitations less strict and adds transparent inheritance cache. Inheritance cache eliminates only part of redundancy, in comparison to preloading. It should be a bit slower, but it will work out of the box. Thanks. Dmitry. > Hey Dmitry > > Out of curiousity: how does this compare to preloading? From what I > understand preloading also links classes, which was one of the most > important differences between preloading files and simply storing them in > opcache. Does this change mean that preloading becomes much less relevant > since class linking can now also happen at runtime? > > Kind regards > Brent > > > […] > class > > […] > their > > […] > "linking" > > […] > significant > > […] > involved > > […] > memory. > > […] > now > > […]