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 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
