Open joshsedl opened 1 year ago
The GUI shouldn't be our problem. People using this will find a solution.
As ddev xdebug on
already exists for ddev, I'd suggest to add a command like
ddev xdebug mode X
which can be any of these values:
https://xdebug.org/docs/profiler#mode
The risky part is, if someone forgets to change it back to a different mode... But no idea how to do it better, yet.
BTW: Also see https://symfony.com/doc/current/profiler.html which mitigates this a bit. I think this is what drupal webprofiler toolbar uses...
I am against an xdebug mode command, as we can enable multiple modes if needed, currently coverage and debug are enabled. And as we only enable xdebug during usage and disable it afterwards, we can just add "profile" to the roster, without hindering performance in any way.
For the GUI, the xdebug documentation recommends https://github.com/jokkedk/webgrind and https://sourceforge.net/projects/qcachegrindwin/ for Windows. See https://xdebug.org/docs/profiler
But yea, maybe the symfony profiler is actually the way to go! We should test both.
Yes and I think we should indeed have both. Sorry, my understanding was, that it's profile xor debug, but I might be wrong!
Separate issue for VSCode UI Integration: https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/issues/128
Looks great! Thanks for the link!
We should add a command, that enables xdebug and puts it in profiling mode (xdebug.mode = profile).
This way, we can analyse our Code for performance, and see, where performance is problematic.
Unfortunately there is no maintained GUI for inspecting the profiling file properly under Windows. Our only option is WinCacheGrind. Under Linux, there is the maintained KCacheGrind by the wonderful KDE Team.
Solution: We should switch to a Linux based System 😵💫