The nice thing about a module which dumps external files is taht you can use the raw data in any number of ways. For example with APD, you can generate a complete call graph, provide statics inclusive or exclusive of child calls, and do rather arbitrary type sorting. This is seems to be the standard for profiling software, as this is what gcc's gprof and perl's DProf do. Since (at least with APD, I assume with DGB as well), you can set and unset the profiler from the application with a php function call, you still have the ability to enable/disable the profiler in the application based on arbitrary application logic.
Also, calling to an external profiler (in php, as you do) generates a large amount of overhead. You should consider using times() over gettimeofday() in your handler, it's much cheaper and provides less overhead bias. George On Sunday, July 28, 2002, at 08:15 AM, <[EMAIL PROTECTED]> wrote: > Hello, I made a patch to add PHP profiling support to the PHP language. > It adds 'set_profile_handler' and 'restore_profile_handler' that work > similar to the 'set_error_handler' and 'restore_error_handler' functions > and are the minimum needed to allow people to profile their PHP code > directly from PHP. The rationale behind adding support to the PHP > language for this rather than doing it behind the scenes with C modules > is to give people a lot of flexibility over the profiling of their > applications and the resulting data. It makes it really easy to do > things like save the result to your application's database, profile only > on certain conditions and/or for certain users, and lets you easily > display the profiling report on the same page that was profiled for > example, which saves developers from having to cross-reference profiling > logs all the time. > > The patch, an example profiler that uses it written in PHP, and some > example screenshots of that are at: > http://www-cse.ucsd.edu/~sbrown/profiler/php-profiler.html > The patch is against 4.2.1 and 4.1.2, but is clean on 4.2.2 and surely > many other versions. > > I wasn't sure how PHP's symbol table is affected by function calls, so I > strduped the function name and file name across the function call to > make sure nothing bad would happen to them. While it works fine, that > information is probably preserved somewhere already so the strdups could > be removed. > > // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
