[php-src] Issue #11644: Declare typed properties for internal classes without backing storage

From: Date: Sat, 08 Jul 2023 23:20:22 +0000
Subject: [php-src] Issue #11644: Declare typed properties for internal classes without backing storage
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-244919@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/11644 Author: nielsdos ### Description arginfo.h files contain calls to zend_declare_typed_property to create the property info and the backing storage. The backing storage is not always necessary though, for example in ext/dom (and I think ext/date too, maybe others too), there are custom read_property and write_property handlers that write to an underlying struct instead of in the backing storage. The backing storage is therefore always of value UNDEF. It would be great if there was an option, e.g. via the stub generator, to avoid the allocation of these backing storages. This has two advantages: * Less memory usage per class instance * When the extension creates a lot of objects, a lot of time can be spent in filling in those useless backing storages. This can be seen in a profile where a lot of ext/dom objects are created for example, which is not an uncommon scenario. There are of course difficulties in implementing this: * There is an offset field in the property info should point to the backing storage. If we don't have one, then we break assumptions of the users of this field. * The engine uses default_properties_count (and similar for statics) to track the amount of used storage, but if there is no backing storage, then it will be 0 and the engine will incorrectly assume there are no properties. I'm not sure if this is worth it given the complications above. However, I have a feeling something like this might be easier after https://wiki.php.net/rfc/property-hooks would be merged. That's because conceptually this feature request ties in nicely with the property hooks that don't have backing storage.

« previous php.bugs (#244919) next »