# ZTS performance

- Thread: https://externals.io/message/206
- Original archive: https://news-web.php.net/php.internals/206
- Started by Wojtek Meler on 2003-03-24T12:58:21+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #206 — Wojtek Meler — 2003-03-24T12:58:21+00:00

URL: https://externals.io/message/206#206

Hi!

I've done some performance tests of PHP with and without ZTS (RH7.2 -
pthreads). I've noticed that ZTS is signifcally slower than normal mode. My
machine was able to response for 100reqs/s without ZTS and 95reqs/s with ZTS.
When I turned on turck mmcache (code cache & optimizer) it handled 400reqs/s
without ZTS and 300reqs/s with ZTS. 

I think, that it is not mmcache problem, but ZE problem. Probably parsing cost
is similar in ZTS and normal mode, and it is so large that hide execution cost
difference in ZTS and nonZTS mode. That's why I got  100reqs/s in both ZTS and
nonZTS mode (that gives 10ms/request). 

Difference betwen 300 and 400 reqs/s is only 0.8ms.

10% of it is mmcache (restoring from cache takes 0.14ms in nonZTS and 0.21ms in
ZTS). The rest is script execution overhead.

Actually mmcache doesn't copy any opcodes - it only registers classes and
functions. The same code is called both in ZTS and nonZTS mode. Difference is
50% overhead in ZTS !!!

Does anyone have any suggestions ? Maybe I should use different thread library ?
Maybe TSRM should be rewritten ? 
Does anyone have any similar results (with code caching) ?

regards,
Wojtek

---

## #231 — Zeev Suraski — 2003-03-24T20:04:59+00:00

URL: https://externals.io/message/206#231 · In reply to: #206

ZTS is *always* going to be slower than non ZTS.  There's no need for 
rewriting TSRM, it's roughly as fast as it can be.  We may still be able to 
squeeze a bit more performance by reducing the number of fetches, but most 
fetches have already been eliminated, so I don't anticipate too much gains 
here.  As Andi mentioned, about a year and a half ago we worked furiously 
to reduce the number of fetches.  Most of those remaining are either too 
difficult to get rid of, or too ugly to get rid of.  If people come up with 
patches that reduce the number of fetches, I'll be more than happy to go 
over them and commit them if they don't mess up the code too much...

Note that only some of the slowdown is coming from fetches.  Much of it is 
incurred by having to just do more - send extra arguments to virtually all 
function calls (when the context is passed, rather than fetched), having to 
calculate access to global elements in runtime instead of compile time, 
(CG(foo) resolves to a 'static' reference in non-ZTS, but a pointer based 
reference in ZTS), perform locking (very much reduced in modern versions of 
TSRM thanks to the Zeus guys) and use thread-safe system calls.  Thread 
safety costs!

Zeev

At 04:58 24/03/2003, Wojtek Meler wrote:
>Hi!
>
>I've done some performance tests of PHP with and without ZTS (RH7.2 -
>pthreads). I've noticed that ZTS is signifcally slower than normal mode. My
>machine was able to response for 100reqs/s without ZTS and 95reqs/s with ZTS.
>When I turned on turck mmcache (code cache & optimizer) it handled 400reqs/s
>without ZTS and 300reqs/s with ZTS.
>
>I think, that it is not mmcache problem, but ZE problem. Probably parsing cost
>is similar in ZTS and normal mode, and it is so large that hide execution cost
>difference in ZTS and nonZTS mode. That's why I got  100reqs/s in both ZTS and
>nonZTS mode (that gives 10ms/request).
>
>Difference betwen 300 and 400 reqs/s is only 0.8ms.
>
>10% of it is mmcache (restoring from cache takes 0.14ms in nonZTS and 
>0.21ms in
>ZTS). The rest is script execution overhead.
>
>Actually mmcache doesn't copy any opcodes - it only registers classes and
>functions. The same code is called both in ZTS and nonZTS mode. Difference is
>50% overhead in ZTS !!!
>
>Does anyone have any suggestions ? Maybe I should use different thread 
>library ?
>Maybe TSRM should be rewritten ?
>Does anyone have any similar results (with code caching) ?
>
>regards,
>Wojtek