webgrind
webgrind copied to clipboard
jokkedk
All costs show "0.00"
Very new to this software, trying to get it set up locally to diagnose issues with a client's site. Running in to a strange problem where absolutely no timing data exists. You can see in the screenshot "4452 different functions called in milliseconds ( runs, 4452 shown)" (missing the actual number of milliseconds), as well as "0.00" for all costs. Very frustrating.
Ubuntu 18.04.4 64-bit (WSL1) PHP 7.4.3
I thought this might be related to #119, but trying that patch did not solve the issue.
I recently ran into this. Deleting the old bin/preprocessor fixed it for me.
For what it's worth, I just ran into this, but realized that my script had an error (exceeded the max_execution_time). For whatever reason this resulted in 0s in the time columns.
Seems to still exist in 1.8 downloaded from Github as run on a Debian system with PHP7.3 - same cachegrind.out produces correct (or so presumed) cost summaries on version 1.2 but will only have 0.00 when analyzed with 1.8.
I have this problem with scripts that have too many calls or long run time.
Debugging the process, I saw that the "summary" header was not set in those runs.
At one point I made a test disabling the binary preprocessor so I could test it with PHP, and that one worked just fine, so it's a difference in the implementation.
@jokkedk @alpha0010
I managed to fix it by changing on the preprcessor.cpp the types of FunctionData.invocationCount, summedSelfCost and summedInclusiveCost from int to long. I don't know much cpp, probably unsigned int or something else is more appropriate.
From that point on, the results from the binary and php preprocessors are the same.
Xdebug 3 has a change in timing resolution. https://github.com/jokkedk/webgrind/pull/145 partially fixed that with changes to the reader. However, that fix means integer overflow on 32-bit values means anything running longer than about 45 seconds will likely give wrong values. Using unsigned (which it was supposed to be doing already...) would support double that. uint32_t would be the type to use (which is likely what PHP processor is doing internally).