|Re: [pdt-dev] Profiler for Xdebug|
as recommended, I tried to implement the ProfilerDB Interface for XDebug.
I could not test anything, because I need to know, how the class XDProfilerDB will be called â sorry Iâm new to PDT 😊
Next should be to invoke the profiler class right after profiling session by providing a org.eclipse.php.internal.debug.core.xdebug.cachegrind.Tree which is created by org.eclipse.php.internal.debug.core.xdebug.cachegrind.Parser using a cachegrind file. The latter Task is already done in https://git.eclipse.org/r/#/c/98595/2/plugins/org.eclipse.php.phpunit/src/org/eclipse/php/phpunit/ui/launch/PHPUnitXDLauncher.java line 254.
Could you please point me to place, where I can start invocation of XDProfilerDB?
Gesendet von Mail fÃr Windows 10
As Michal already said, it is very nice that you would like to contribute such a great feature :)! I am moving this discussion to PDT development mailing group as I think that other team members may also add value to this topic.
As a first step I would like to describe briefly what I think we can do to add another profiler based on Xdebug. First of all, the currently available profiler is based on Zend Debugger and all supporting code was moved from Zend Studio and added as a separate feature for PDT. As you have probably already noticed, there is no common API in PDT core plug-ins for profiling support. Everything is packed in new feature for Zend Profiler. As I am not too familiar yet with internals for Xdebug profiling in general (and differences with Zend Debugger profiler data) I can not say what would be needed to create a common API that would work for both profilers. Anyway as you already started some analysis I guess that you will be able to tell me what is missing or would have to be refactored to handle Xdebug profiler data.
As an entry point I suggest to take a look at org.eclipse.php.profile.core.engine and org.eclipse.php.profile.core.data packages and related classes/interfaces (especially ProfilerDB interface which I think may be reworked to serve both profilers as an entry point for profiling result data). If you would be able to provide Xdebug implementation for this interface then everything else should be a little bit straight forward. But as I already said it would be nice if you can investigate/suggest what need to be changed to create common API that would serve both profilers. If you find it possible to provide such implementation we can think about extracting some common part of API for both profilers and moving it directly to PDT core plug-ins.
On 6/4/2017 9:10 PM, Michal Niewrzal wrote: