New in 3.0: Xdebug profiler integration

Hello everybody,

Xdebug is a great tool and many of you use it for interactive debugging. But Xdebug is not just a debugger, it also provides many other features such as profiling or code coverage

Integration with Xdebug Profiler is one of the most voted feature in the PhpStorm issue tracker, so we are happy to announce that its initial support is already implemented in PhpStorm 3.0 EAP!

To be more specific – PhpStorm provides visual representation of profiling data generated by Xdebug. In order to open a profiler snapshot, invoke the ‘Analyze Xdebug profiler snapshot’ action and select the path to the snapshot. Note that you can select several snapshots at a time and collect the aggregated profiling information.

'Analyze Xdebug profiler snapshot' action in 'Tools' menu

By now we have implemented the following data views:

  • ‘Execution Statistics’ – displays summary information about execution metrics of every called function.

    'Execution Statistics' view

  • ‘Call Tree’ – displays the execution paths of the called functions.

    'Call Tree' view

  • ‘Callees’ – same as ‘Call Tree’ but with the selected function as the root.
  • ‘Callers’ – all the paths that can result in calling the selected function.

To learn how to configure the Xdebug extension so profiling is enabled follow official documentation at http://xdebug.org/docs/profiler#starting. You can use our Xdebug bookmarklets generator to toggle profiling directly from browser toolbar.

Developing integration with the profiler is still in progress, so we are looking forward for your feedback!

Develop with pleasure!

This blog is permanently closed.

For up-to-date information please follow to corresponding WebStorm blog or PhpStorm blog.

 
This entry was posted in Cool Feature, PhpStorm and tagged , , . Bookmark the permalink.

10 Responses to New in 3.0: Xdebug profiler integration

  1. ragtek says:

    Can anybody help me with this?
    The browser cookie is working nice, but i can’t run the profiler:(

    that’s the relevant part of my php.ini
    Have i forgotten something?

    zend_extension = C:\xampp\php\ext\php_xdebug-2.1.0-5.3-vc6.dll

    ; xdebug.auto_trace
    ; Type: boolean, Default value: 0
    ; When this setting is set to on, the tracing of function calls will be enabled just before the
    ; script is run. This makes it possible to trace code in the auto_prepend_file.
    xdebug.auto_trace = 1

    ; xdebug.collect_includes
    ; Type: boolean, Default value: 1
    ; This setting, defaulting to On, controls whether Xdebug should write the filename used in include
    ; (), include_once(), require() or require_once() to the trace files.
    ;xdebug.collect_includes = 1

    ; xdebug.collect_params
    ; Type: integer, Default value: 0
    ;
    ; This setting, defaulting to 0, controls whether Xdebug should collect the parameters passed to
    ; functions when a function call is recorded in either the function trace or the stack trace.
    ;xdebug.collect_params = 0

    ; xdebug.collect_return
    ; Type: boolean, Default value: 0
    ; This setting, defaulting to Off, controls whether Xdebug should write the return value of function
    ; calls to the trace files.
    ;xdebug.collect_return = 0

    ; xdebug.collect_vars
    ; Type: boolean, Default value: Off
    ; This setting tells Xdebug to gather information about which variables are used in a certain scope.
    ; This analysis can be quite slow as Xdebug has to reverse engineer PHP's opcode arrays. This setting
    ; will not record which values the different variables have, for that use xdebug.collect_params. This
    ; setting needs to be enabled only if you wish to use xdebug_get_declared_vars().
    ;xdebug.collect_vars = "Off"

    ; xdebug.default_enable
    ; Type: boolean, Default value: On
    ; If this setting is On then stacktraces will be shown by default on an error event. You can disable
    ; showing stacktraces from your code with xdebug_disable(). As this is one of the basic functions of
    ; Xdebug, it is advisable to leave this setting set to 'On'.
    xdebug.default_enable = "On"

    ; xdebug.dump.*
    ; Type: string, Default value: Empty
    ; * = COOKIE, FILES, GET, POST, REQUEST, SERVER, SESSION. These seven settings control which data
    ; from the superglobals is shown when an error situation occurs. Each php.ini setting can consist of
    ; a comma seperated list of variables from this superglobal to dump, but make sure you do not add
    ; spaces in this setting. In order to dump the REMOTE_ADDR and the REQUEST_METHOD when an error
    ; occurs, add this setting:
    ;
    ; xdebug.dump.SERVER = REMOTE_ADDR,REQUEST_METHOD
    ; xdebug.dump.SERVER = REMOTE_ADDR,REQUEST_METHOD
    ;xdebug.dump.COOKIE = ""
    ;xdebug.dump.FILES = ""
    ;xdebug.dump.GET = ""
    ;xdebug.dump.POST = ""
    ;xdebug.dump.REQUEST = ""
    ;xdebug.dump.SERVER = ""
    ;xdebug.dump.SESSION = ""

    ; xdebug.dump_globals
    ; Type: boolean, Default value: 1
    ; Controls whether the values of the superglobals as defined by the xdebug.dump.* settings whould be
    ; shown or not.
    ;xdebug.dump_globals = 1

    ; xdebug.dump_once
    ; Type: boolean, Default value: 1
    ; Controls whether the values of the superglobals should be dumped on all error situations (set to
    ; Off) or only on the first (set to On).
    ;xdebug.dump_once = 1

    ; xdebug.dump_undefined
    ; Type: boolean, Default value: 0
    ; If you want to dump undefined values from the superglobals you should set this setting to On,
    ; otherwise leave it set to Off.
    ;xdebug.dump_undefined = 0

    ; xdebug.extended_info
    ; Type: integer, Default value: 1
    ; Controls whether Xdebug should enforce 'extended_info' mode for the PHP parser; this allows Xdebug
    ; to do file/line breakpoints with the remote debugger. When tracing or profiling scripts you
    ; generally want to turn off this option as PHP's generated oparrays will increase with about a third
    ; of the size slowing down your scripts. This setting can not be set in your scripts with ini_set(),
    ; but only in php.ini.
    ;xdebug.extended_info = 1

    ; xdebug.file_link_format
    ; Type: string, Default value: *empty string* , Introduced in Xdebug 2.1
    ;
    ; This setting determines the format of the links that are made in the display of stack traces where
    ; file names are used. This allows IDEs to set up a link-protocol that makes it possible to go
    ; directly to a line and file by clicking on the filenames that Xdebug shows in stack traces.
    ;xdebug.file_link_format = ""

    ; xdebug.idekey
    ; Type: string, Default value: *complex*
    ; Controls which IDE Key Xdebug should pass on to the DBGp debugger handler. The default is based on
    ; environment settings. First the environment setting DBGP_IDEKEY is consulted, then USER and as last
    ; USERNAME. The default is set to the first environment variable that is found. If none could be
    ; found the setting has as default ''.
    ;xdebug.idekey = ""

    ; xdebug.manual_url
    ; Type: string, Default value: http://www.php.net
    ; This is the base url for the links from the function traces and error message to the manual pages
    ; of the function from the message. It is advisable to set this setting to use the closest mirror.
    ;xdebug.manual_url = "http://www.php.net"

    ; xdebug.max_nesting_level
    ; Type: integer, Default value: 100
    ; Controls the protection mechanism for infinite recursion protection. The value of this setting is
    ; the maximum level of nested functions that are allowed before the script will be aborted.
    xdebug.max_nesting_level = 100

    ; xdebug.overload_var_dump
    ; Type: boolean, Default value: 1 , Introduced in Xdebug 2.1
    ; By default Xdebug overloads var_dump() with its own improved version for displaying variables when
    ; the html_errors php.ini setting is set to 1. In case you do not want that, you can set this setting
    ; to 0, but check first if it's not smarter to turn off html_errors.
    ;xdebug.overload_var_dump = 1

    ; xdebug.profiler_append
    ; Type: integer, Default value: 0
    ; When this setting is set to 1, profiler files will not be overwritten when a new request would map
    ; to the same file (depnding on the xdebug.profiler_output_name setting. Instead the file will be
    ; appended to with the new profile.
    xdebug.profiler_append = 1

    ; xdebug.profiler_enable
    ; Type: integer, Default value: 0
    ; Enables Xdebug's profiler which creates files in the profile output directory. Those files can be
    ; read by KCacheGrind to visualize your data. This setting can not be set in your script with ini_set
    ; ().
    xdebug.profiler_enable = 1

    ; xdebug.profiler_enable_trigger
    ; Type: integer, Default value: 0
    ; When this setting is set to 1, you can trigger the generation of profiler files by using the
    ; XDEBUG_PROFILE GET/POST parameter. This will then write the profiler data to defined directory.
    xdebug.profiler_enable_trigger = 0

    ; xdebug.profiler_output_dir
    ; Type: string, Default value: /tmp
    ; The directory where the profiler output will be written to, make sure that the user who the PHP
    ; will be running as has write permissions to that directory. This setting can not be set in your
    ; script with ini_set().
    xdebug.profiler_output_dir = "C:\xampp\tmp"

    ; xdebug.profiler_output_name
    ; Type: string, Default value: cachegrind.out.%p
    ;
    ; This setting determines the name of the file that is used to dump traces into. The setting
    ; specifies the format with format specifiers, very similar to sprintf() and strftime(). There are
    ; several format specifiers that can be used to format the file name.
    ;
    ; See the xdebug.trace_output_name documentation for the supported specifiers.
    xdebug.profiler_output_name = "xdebug_profile.%R::%u"

    ; xdebug.remote_autostart
    ; Type: boolean, Default value: 0
    ; Normally you need to use a specific HTTP GET/POST variable to start remote debugging (see Remote
    ; Debugging). When this setting is set to 'On' Xdebug will always attempt to start a remote debugging
    ; session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.
    xdebug.remote_autostart = 1

    ; xdebug.remote_enable
    ; Type: boolean, Default value: 0
    ; This switch controls whether Xdebug should try to contact a debug client which is listening on the
    ; host and port as set with the settings xdebug.remote_host and xdebug.remote_port. If a connection
    ; can not be established the script will just continue as if this setting was Off.
    xdebug.remote_enable = 1

    ; xdebug.remote_handler
    ; Type: string, Default value: dbgp
    ; Can be either 'php3' which selects the old PHP 3 style debugger output, 'gdb' which enables the GDB
    ; like debugger interface or 'dbgp' - the brand new debugger protocol. The DBGp protocol is more
    ; widely supported by clients. See more information in the introduction for Remote Debugging.
    xdebug.remote_handler = "dbgp"

    ; xdebug.remote_host
    ; Type: string, Default value: localhost
    ; Selects the host where the debug client is running, you can either use a host name or an IP
    ; address.
    xdebug.remote_host = "localhost"

    ; xdebug.remote_log
    ; Type: string, Default value: none
    ; If set to a value, it is used as filename to a file to which all remote debugger communications are
    ; logged. The file is always opened in append-mode, and will therefore not be overwritten by default.
    ; There is no concurrency protection available.
    ;xdebug.remote_log = "none"

    ; xdebug.remote_mode
    ; Type: string, Default value: req
    ;
    ; Selects when a debug connection is initiated. This setting can have two different values:
    ;
    ; req
    ; Xdebug will try to connect to the debug client as soon as the script starts.
    ; jit
    ; Xdebug will only try to connect to the debug client as soon as an error condition occurs.
    xdebug.remote_mode = "req"

    ; xdebug.remote_port
    ; Type: integer, Default value: 9000
    ; The port to which Xdebug tries to connect on the remote host. Port 9000 is the default for both the
    ; client and the bundled debugclient. As many clients use this port number, it is best to leave this
    ; setting unchanged.
    xdebug.remote_port = 9000

    ; xdebug.show_exception_trace
    ; Type: integer, Default value: 0
    ; When this setting is set to 1, Xdebug will show a stack trace whenever an exception is raised -
    ; even if this exception is actually caught.
    ;xdebug.show_exception_trace = 0

    ; xdebug.show_local_vars
    ; Type: integer, Default value: 0
    ; When this setting is set to something != 0 Xdebug's generated stack dumps in error situations will
    ; also show all variables in the top-most scope. Beware that this might generate a lot of
    ; information, and is therefore turned off by default.
    ;xdebug.show_local_vars = 0

    ; xdebug.show_mem_delta
    ; Type: integer, Default value: 0
    ; When this setting is set to something != 0 Xdebug's human-readable generated trace files will show
    ; the difference in memory usage between function calls. If Xdebug is configured to generate
    ; computer-readable trace files then they will always show this information.
    ;xdebug.show_mem_delta = 0

    ; xdebug.trace_format
    ; Type: integer, Default value: 0
    ; The format of the trace file.
    ;
    ; See the introduction of Function Traces for a few examples.
    ;xdebug.trace_format = 0

    ; xdebug.trace_options
    ; Type: integer, Default value: 0
    ; When set to '1' the trace files will be appended to, instead of being overwritten in subsequent
    ; requests.
    ;xdebug.trace_options = 0

    ; xdebug.trace_output_dir
    ; Type: string, Default value: /tmp
    ; The directory where the tracing files will be written to, make sure that the user who the PHP will
    ; be running as has write permissions to that directory.
    ; xdebug.trace_output_name
    xdebug.trace_output_dir = "C:\xampp\tmp"

    ; Type: string, Default value: trace.%c
    ;
    ; This setting determines the name of the file that is used to dump traces into. The setting
    ; specifies the format with format specifiers, very similar to sprintf() and strftime(). There are
    ; several format specifiers that can be used to format the file name. The '.xt' extension is always
    ; added automatically.
    ;xdebug.trace_output_name = "trace.%c"

    ; xdebug.var_display_max_children
    ; Type: integer, Default value: 128
    ; Controls the amount of array children and object's properties are shown when variables are
    ; displayed with either xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This
    ; setting does not have any influence on the number of children that is send to the client through
    ; the Remote Debugging feature.
    ;xdebug.var_display_max_children = 128

    ; xdebug.var_display_max_data
    ; Type: integer, Default value: 512
    ; Controls the maximum string length that is shown when variables are displayed with either
    ; xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This setting does not have
    ; any influence on the amount of data that is send to the client through the Remote Debugging
    ; feature.
    ;xdebug.var_display_max_data = 512

    ; xdebug.var_display_max_depth
    ; Type: integer, Default value: 3
    ; Controls how many nested levels of array elements and object properties are when variables are
    ; displayed with either xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This
    ; setting does not have any influence on the depth of children that is send to the client through the
    ; Remote Debugging feature.
    ;xdebug.var_display_max_depth = 3

  2. Sergey Shymko says:

    In general, your configuration looks fine. The only suspicious line as for me is ‘xdebug.profiler_output_name = “xdebug_profile.%R::%u”‘. It specifies the file name that contains the colon symbol. From your listing I assume that you’re running Windows, so the file system is probably NTFS or FAT. Both of them disallow to use ‘:’ for a file name.

  3. Marcus Bointon says:

    Any chance of lovely graphical profile time/call maps like kcachegrind does?

  4. is there a way to set the profiler_output_dir to output per domain?

    right now on my dev machine i have many projects.

    I would like to set the profiler output for the site to appear within the currently setup FTP area so i can download it from within PhpStorm via the “Remote Host” panel.
    /var/www/vhosts/admin/somesite.com/httpdocs/profiler_output
    /var/www/vhosts/admin/different-site.com/httpdocs/profiler_output
    /var/www/vhosts/admin/yet-another-site.com/httpdocs/profiler_output
    /var/www/vhosts/admin/some-other-site.com/httpdocs/profiler_output

    If I set the profiler_output_dir to a fixed location on the remote dev machine I have to go outside PhpStorm to transfer the profiler output back to my local machine to then run the profiler. Hoping to avoid leaving PhpStorm.

    Possible?

  5. Pingback: New in 3.0: Support of profiling with Zend Debugger | WebStorm & PhpStorm Blog

  6. Maxime says:

    I guess you can setup different output dir in the configuration of you vhosts

    php_value xdebug.profiler_enable 0
    php_value xdebug.profiler_enable_trigger 1
    php_value xdebug.profiler_output_name ‘cachegrind.out.%u’
    php_value xdebug.profiler_output_dir …

Comments are closed.