View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001701||Xdebug||Feature/Change request||public||2019-09-14 12:06||2019-10-07 14:57|
|Status||resolved||Resolution||no change required|
|Platform||Docker linux||OS||MAC||OS Version||Mojave|
|Target Version||Fixed in Version|
|Summary||0001701: Slowness due to calls to getTimeOfDay|
|Description||When running xDebug within a docker container under MAC OS the performance is very degraded, much worse than the usual (and expected) degraded performance. This is due to the way that calls to getTimeOfDay is handled by the system in this setup, as described here https://github.com/docker/for-mac/issues/3455|
Under this setup these calls are very slow and account for most of the degradation in performance. We confirmed this by rebuilding Xdebug and removing the call to this function that is done in xdebug_get_utime in usefulstuff.c
Here are the results of our benchmark of running a symfony command
Without Xdebug: 15s
With Xdebug and calling getTimeOfDay: 6m30s
With Xdebug and without calling getTimeOfDay: 2m10s
As you can see the extra degradation in performance is huge.
This call to getTimeOfDay is done by xdebug_add_stack_frame to save this data into the time field in the stack entry. This only seems to be used when printing stack traces. I guess that 99% of users are not interested in this data. If there was a way of disabling calling xdebug_get_utime within this function this should solve the issue for the majority of users
- Add a new config setting to enable or disable saving the time in the stack frame. (enabled for BC compatibility), OR
- Only perform this call if tracing is enabled for the current context
|Steps To Reproduce||Enable xdebug in a docker container running PHP under MAC OS. Run any process. It will be more than 2x slower than the same process not running under this setup|
|Operating System||MAC OS|
I can't reproduce this myself, as I don't have a Mac.
I am reluctant to add a specific setting for this, as there are already too many settings in Xdebug. My plan for Xdebug 3 is to drastically reduce the amount of settings as well.
As the timestamps form part of the stack traces that Xdebug generates, this data needs to be collected for each function call. I'm happy to use a different clock-getting-function on OSX, besides gettimeofday() if one exists.
Thanks for your report. After reading the explanation that you've linked, and think a bit more about this, I have come to the conclusion that I do not want to add a new setting as a workaround a bug in Docker on Mac. This should definitely be fixed on their site, and their bug also does not exclusively hit Xdebug.
|2019-09-14 12:06||barel||New Issue|
|2019-09-14 12:06||barel||Tag Attached: performance|
|2019-09-16 16:43||derick||Note Added: 0005141|
|2019-10-07 14:57||derick||Assigned To||=> derick|
|2019-10-07 14:57||derick||Status||new => resolved|
|2019-10-07 14:57||derick||Resolution||open => no change required|
|2019-10-07 14:57||derick||Note Added: 0005169|