[xdebug-general] xdebug performance enhancements

We use PHP at work, and have used xdebug+PHPunit with code coverage to
help us keep track of how things are going. But it takes a very long
time to run with coverage, and a huge amount of memory. Coverage in
other languages doesn't seem to take as long to generate, so I took a
peek at xdebug's code to see if there were any easy performance wins
to be had. I think I found a couple!

I've put my changes up on a github fork. I don't know what the
standard procedure is for submitting code to xdebug; any suggestions
are welcome.

Aside from code inspection, I had trouble getting PHP (and therefore
xdebug) to build with appropriate settings to use gprof (on Linux) or
Saturn (on OSX). OSX's Shark app also refused to find the debug
symbols (which GDB had no issues with). So I did the poor-man's
sampling profiling by running PHP under GDB and hitting ^C
periodically to see where it was.

branch use_lineno_index
The first thing I noticed was that a bunch of my GDB interruptions
caught xdebug in xdebug_sprintf(), particularly the place where it
converts lineno into sline. Given that the xdebug_hash functions
accept either a string+length or an integer, and the line number
already comes in as an integer…
https://github.com/taavi/xdebug/commit/1b99e52216962e88a72a4cb0625070ddec254f68

branch cache_filename
Once I got rid of the xdebug_sprintf(), the next hot spot was the
string hash function. I figure that most executions hit the same file
repeatedly, so caching the filename and using strcmp instead of
hashing-and-looking-up should help. And it seems to (a lot)!
https://github.com/taavi/xdebug/commit/8ca255ff34a303fe51efd877e48e343ee4c0bc30

I also tried something to reduce memory usage, but it didn't help
much. I have some more ideas though, and will write again if they bear
fruit.

I did a bit of benchmarking with one of our test subsuites (37 tests,
108 assertions). It hits a local MySQL database, which explains the 5s
no-coverage run. I'd initially made a degenerate test (one file, runs
a function 1000000 times) which claims even better performance gains,
but I think this google spreadsheet shows the kinds of gains one can
expect in the real world:
https://spreadsheets.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0AlxHwOOM4sEudG12YUNJZGVKV25oVFA2Vy02TUZYMnc&output=html

And thanks for providing a debugger/coverage/stack protection extension for PHP!

-- 
taa
/*eof*/