Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter
| From: | Andi Gutmans | Date: | Sat, 08 Jun 2002 07:41:41 +0000 |
| Subject: | Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-85027@lists.php.net to get a copy of this message | ||
At 09:12 PM 6/7/2002 -0700, Brian Pane wrote:
In case it's helpful to the PHP developers, here are some more performance problems that I found by running a quick system call profile of PHP-4.2.1 within Apache-2.0.37-dev: * php_request_shutdown() calls shutdown_memory_manager(), which does a large number of calls to free() per request. If there's any way to get the PHP allocator to use an APR pool, that should help speed things up a lot. (The mallocs and frees are going to be especially problematic within multithreaded MPMs.)We're already doing this for Win32. Check out ZEND_DO_MALLOC/ZEND_DO_FREE/ZEND_DO_REALLOC in zend_alloc.c. Note that in Win32 we only skip the free's if we're in release mode. If we're in debug mode we use a per-thread pool but we do the frees because it's our memory leak detector.
* The lex_scan() function consumed a lot of CPU time, even though in my test case (a file with no actual embedded scripting code) only the loop right after the "yy_match" label ever got executed.In general I've profiled PHP and the scanning stage doesn't take too much CPU time. You shouldn't test an empty html page but rather a real-life PHP script. I've profiled PHP a lot and be aware that the profiling results change a lot according to what script you're running. As it's gone through various optimizations already there isn't an easy to find bottleneck. Andi