-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inaccurate measurements of time (under some/all conditions?) #4
Comments
Same here. Version 1.0.0.14 (last one on Sourceforge) reports 9731 ms and current 1.1 973ms on the same .out file. A xdebug Profile is also ~ 9 Sec. |
Same here |
I don't know when or if there'll be a fix. |
I can confirm the problem with the latest version. All times are 1/10 of the times in the cachegrind files. You can easily test it with just sleep(1) in a php file. |
Xdebug 3.1.6 is using 10ns units, and the millisecond calculations are perfectly fine in WinCachegrind 1.1.0.16. FYI the problematic cachegrind file in the linked bug is oddly using 1 microsecond units, and is specifying it as "Time" in the header. Looks like WinCacheGrind is assuming 10ns units by default, maybe it is ignoring the unit defined in the events header? I think it would be great if the unit should just be configurable, no reason to try to autodetect it from the header. I can confirm that everything looks great when I am looking at cachegrind files generated with Xdebug 3.1.6. Actually, Webgrind is off by the fraction of 10 since this Xdebug PR was released: QCacheGrind/KCacheGrind are just using the raw values, so they are totally unreadable due to printing the 10ns units as is. |
From Ephraim Rubenstein [email protected] :
I downloaded 3 Cachegrind viewers today.
WebCacheGrind is showing measurements approx 1/10 of the other 2
WebCacheGrind Zend\MVC\Application->init 49ms
WebGrind 492ms and
QCacheGrind 492 253 (microsecs)
This does not make sense .
Can you advise?
TIA
Efffy
The text was updated successfully, but these errors were encountered: