Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000077XdebugUsage problemspublic2004-07-16 06:162012-06-02 19:08
ReporterRoger Keays 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target Version2.2devFixed in Version 
Summary0000077: Profiler doesn't handle recursive functions
DescriptionThe xdebug profiler seems to be unable to handle recursion properly. given the script:
 
<?php
 
function c() {
  d();
}
function d() {
 
  static $x;
  if (!isset($x)) $x = 0;
  $x++;
  while ($x < 20) c();
}
 
c();
 
?>
 
We see the results
 
c() - cumulative: 1014.75% self: 49.36%
d() - cumulative: 965% self: 47.87%
main - cumulative: 100% self: 2.66%
 
self still sums to approx 100%, but the cumulative time is all wrong.


Having a look at the cachegrind.out file it is pretty clear what is happening - xdebug is counting the first call to d() in the total of the second call to d() - which is okay, but since it prints both to the file you end up with the equivalent of 3 calls to d().

I wouldn't accept filtering the linked list for function names the match the exiting function when summing totals as a valid solution for this defect, since recursion may be hidden at a distance of more than 1 function call away.

Can't think of a quick fix for this one...
TagsNo tags attached.
Operating System
PHP Version4.3.0
Attached Files

- Relationships

-  Notes
(0001536)
eis_os (reporter)
2010-07-23 10:42
edited on: 2010-07-23 16:00

Can the time split by nest level?
So xdebug only sum up the total taken of the current nest level?

Currently my XDebug output here goes crazy, WinCacheGrind telling me percentage values in the 10000% range... (heavily recursion together with Smarty3) (That was actually bug 0000357

(0001537)
eis_os (reporter)
2010-07-23 12:14

A slightly modified testcase (less recursive, more time per call):
<?php
 
function c() {
  usleep(1000);
  d();
}
function d() {
  static $x;
  if (!isset($x)) $x = 0;
  $x++;
  while ($x <30) c();
}
 
c();
 
?>
(0001617)
FloSchnell (reporter)
2010-11-24 16:30

Can confirm this issue.
This, of course, also applies to object methods.
Really hard to realize that there's something wrong because if the program contains more than just nested functions then you won't realize that the cumulative is actually wrong.
It just seemed way too high, which got me looking into the issue ...
(0002189)
dinu (reporter)
2012-05-25 04:06

I desperately need a fix to this, or I will have to go back to ZendDebugger... working on a project where recursion is unavoidable as its goal is to wrap together pieces of self-referencing data.
(0002229)
dinu (reporter)
2012-06-02 19:08

So, here's my 2 cents:
http://www.exteon.ro/ro/produse/unelte-php/xt2callgrind [^]
It's tested with a fairly large script of 100K+ function calls, lots of recursion, results are excellent.

It's a very large computational effort though, I now doubt it can be implemented in real time, might thou be translated in a C post-processing feature.

I do have one related question though, if it's in the Docs I missed it: with the profile or trace trigger, I get timings 200% (for large scripts) to 600% (for small scripts) of the real execution time. Do you have some stats linking real execution time, traced execution time and call overhead? Or what is expected of? Should the overhead be roughly linear with the execution time, or roughly linear with the # of function calls?

- Issue History
Date Modified Username Field Change
2004-07-16 06:16 Roger Keays New Issue
2010-03-20 23:47 derick Target Version => 2.2dev
2010-07-23 10:42 eis_os Note Added: 0001536
2010-07-23 10:45 eis_os Note Edited: 0001536
2010-07-23 10:45 eis_os Note Edited: 0001536
2010-07-23 10:46 eis_os Note Edited: 0001536
2010-07-23 12:14 eis_os Note Added: 0001537
2010-07-23 16:00 eis_os Note Edited: 0001536
2010-11-24 16:30 FloSchnell Note Added: 0001617
2012-05-25 04:06 dinu Note Added: 0002189
2012-06-02 19:08 dinu Note Added: 0002229


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker