Hi Dmitry, > > I thought about it as well. The reason for the additional dereference > > levels is probably ,that every globals structure has its own size. > > That way, it needs to go on the heap. > > Not necessary. In case all the structures are known at MINIT time, we may > realloc()-ate the whole flattened tsrm_tls_entry and then access data faster. > > It may be a problem with dl(), but it must already be problematic in ZTS > build. > Perhaps an idea for this could be to generate a special function for every extension to be exported, like get_module_globals_size(). It could be probably seamlessly integrated into ZEND_DECLARE_MODULE_GLOBALS(), so require no change to the existing code. Then on module load we could realloc() the flattened structure on demand. Still it'd be on heap, but it would be a contiguous chunk of memory.
> > What we indeed could do were handling some specific known structures a > > different way. It'd be like EG and others, that belong to the very > > core and are always available. Other globals, especially from > > extensions that can be built shared, would be probably still handled the old > way. > > Maybe it would be a good start to speedup the very core as first. I'd > > wonder which particular data structures and mechanism you had in mind. > > In https://wiki.php.net/zts-improvement I proposed: > > - make "executor_globals_id" to be constant (it's quite easy to do). > - make all "...globals_id" to keep offsets instead if indexes (this is a > bit more > complex and require changes in TSRM implementation). > Yeah, gotcha. The very core globals should be easy to "prefill" for the flattened structure as the sizes are known at the compile time. All the others could be appended to them, perhaps the way I've suggested above or another if a better one is found. Thanks Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
