I don't think it fixes the issue. A program which does say a sleep(1) would still report different number of cycles when SpeedStep is on.

[Note: We are using CPU cycles (RDTSC counter) as a way to do "elapsed" time (or wall clock time) profiling. If what you are interested in is CPU time, then xhprof_enable() already takes an option flag for CPU time profiling-- namely, XHPROF_FLAGS_CPU. When XHPROF_FLAGS_CPU flag is used, CPU times are measured using getrusage().]

Let me know if I misunderstood your suggestion.

Well, sleep() calls are hardly something one wants to 
profile... :)

I saw that you use the RDTSC counter, but calculate time using 
the CPU frequency inside the xhprof extension. If you just 
left that out, it would no longer be required to disable 
speedstep and numbers would be comparable even across 
different machines.

I am not convinced that RDTSC counter comparison is useful either. Based on our own experience that a significant portion of a PHP request processing time is spent on external IO (database queries, memcache accesses, etc.). Suppose we compare RDTSC counter values directly, and the CPU frequency is downclocked with SpeedStep by half, even if nothing has changed in the execution time, direct RDTSC counter comparison would lead to the wrong conclusion that external IO operations were sped up by two times.

@karsten: sleep() was just an example. The idea is that any time the process is blocked waiting on something, the same issue will kick in. If a call to the DB takes say 0.1 seconds, the cycles (RDTSC) delta reported for the DB call will vary when SpeedStep is turned on. So the proposed solution doesn't help.

closing the issue

Ok, that's a valid point. For my use case that would (at least 
partly) not be a problem, but that depends on what you are 
profiling, of course... Thanks for considering this issue!

PS: Too bad there seems to be only one tool (CoolBook) to 
switch off SpeedStep on a Mac...