Hi Anatol, On 2/14/19 8:44 PM, Anatol Belski wrote: > Hi Dmitry, > >> -----Original Message----- >> From: Dmitry Stogov <dmi...@zend.com> >> Sent: Wednesday, February 13, 2019 12:26 AM >> To: Joe Watkins <krak...@gmail.com>; Bob Weinand <bwo...@php.net>; >> Nikita Popov <ni...@php.net>; Anatol Belski (a...@php.net) <a...@php.net>; >> z...@php.net >> Cc: PHP internals <internals@lists.php.net> >> Subject: ZTS improvement idea >> >> Hi, >> >> >> >> >> After JIT+ZTS related discussion with Joe and Bob, and some related >> analyzes. >> >> I came to more or less formed design idea and described it at >> https://wiki.php.net/zts-improvement >> > 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. > 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). Thanks. Dmitry. > > >> This is not an RFC and I'm not sure, if I like to implement TSRM changes >> myself now. >> > Certainly not an RFC. I'm short of time as well, perhaps it will change in a > couple of months. > > Thanks > > Anatol >
