> ZTS is *always* going to be slower than non ZTS.
Yes, but it can be faster than it is. PHP doesn't use almost any shared resources (compiled regexs?) so why it is so slow ?
It uses lots of globals. These aren't shared resources, but they're resources that in ZTS mode, take more time to access than they do in non-ZTS mode. I mentioned the issues involved with this in my previous email.
Thread-safe syscalls ? I don't think so.
That's one of the reasons, I would guess. The libc memory manager is not very efficient with multiple threads accessing it at once, it has locks (which is one of the reasons we implemented our own in ZE2). It's definitely one of the reasons, and as you know, performance penalties accumulate.
> There's no need for rewriting TSRM, it's roughly as fast as it can be.
Things changes ... Now we have AD2003 and __thread keyword in gcc. I suppose that if we use it we could get rid of all this TSRMLS*. I know - PHP is not for linux only - but we could have it in TSRM implementation.
If __thread is any similar to Tls under Windows (which would be my guess), then we can't use it directly. We're already using pthread_setspecific so we're extremely quick with fetches as it is. As I said, I also doubt very much that our performance penalty is solely due to fetches, but mostly based on other issues, which __thread will not alter in any way. You're more than encouraged to try and implement a __thread based solution in place of the pthread_setspecific solution and see if it makes any difference. If it does, we can investigate further in that direction and see if it's usable.
I'm sure that compiler will optimize it better if __thread keyword will be used instead of TSRMLS*.
Probably not much more than pthread_setspecific. I wouldn't be surprised if __thread is built around that, actually.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
