boseakash7 / webgrind Goto Github PK

1. use Webgrind to show my file
2. select "show percent"

Percents counting is wrong.  It is because summary time counting is wrong.
 It is because 'summary' header in cachegrind.out can appears multiple
times, but Webgrind count only last one.

$ grep -n summary cachegrind.out.current
10457:summary: 979732
26146:summary: 1400280
27733:summary: 169586
36305:summary: 515360
36538:summary: 2604
53556:summary: 410313
58639:summary: 536714
59399:summary: 989956
68154:summary: 945163
76826:summary: 413992
77059:summary: 3331

I use 0.81 version of Webgrind and 2.0.3 version of xdebug.  xdebug config is:
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /tmp/
xdebug.profiler_append = 1
xdebug.profiler_output_name = cachegrind.out.current
xdebug.auto_trace = 1

The following patch solves 'summary time' problem, but I don't know which
problems still exists :(

$ diff -u Reader.php.orig Reader.php                
--- Reader.php.orig     2008-10-02 20:25:54.000000000 +0700
+++ Reader.php 2008-10-02 20:22:32.000000000 +0700
@@ -184,7 +184,9 @@
                        $this->seek($this->headersPos);
                        while($line=$this->readLine()){
                                $parts = explode(': ',$line);
-                               $this->headers[$parts[0]] = $parts[1];
+                               if(isset($this->headers[$parts[0]]))
+                                       $this->headers[$parts[0]] += $parts[1];
+                               else $this->headers[$parts[0]] = $parts[1];
                        }
                }
                return $this->headers;


PS: sorry, I unable to attach original cachegrind file because of NDA :(
But I able to provide you with a screenshot:
http://flickr.com/photos/grundik/2907329718/sizes/o/

My server does not have the "short_open_tag" to be true. 

I changed (see attachment) two lines in index.phtml and it works with the
latest SVN checkout.

There's a bug in the JavaScript where I get an Error in IE.
Actually it's missing a "var" in the line where it gets the options...
  The line is something like options = new Object(); IE was
complaining that options was already initialized and this was actually
a local variable. So adding "var" in front made IE happy. 

What steps will reproduce the problem?
1. Install xdebug in MAMP on OS X
2. Produce a cachegrind file from xdebug
3. Choose cachegrind file in webgrind and click update

What is the expected output? What do you see instead?

I expect to see the processed output in webgrind. Instead a box flashes up
saying "Loading..." then disappears quickly. There is no processed output.

What version of the product are you using? On what operating system?

Using the 1.0 release on Mac OS X using MAMP and xdebug.

Please provide any additional information below.

I've checked and tried various different output directories in the config
file but it makes no difference. I've checked the write settings on the
storage directory and its world writeable. Any ideas to make this work?

Please add:

tr:hover td{
background-color: #FFFFE0;
}

(or another color) to CSS. Increases readability on long lists.

There is an obscure bug in Xdebug that has not been fixed yet. It results
in weird costs written to the cachegrind file.

http://bugs.xdebug.org/view.php?id=357


Here is a part of the cachegrind output file:

fl=php:internal
fn=php::function_exists
330 3

fl=php:internal
fn=php::function_exists
334 2

fl=php:internal
fn=php::function_exists
330 2

fl=php:internal
fn=php::function_exists
334 4293967300

fl=php:internal
fn=php::function_exists
330 1

fl=php:internal
fn=php::function_exists
334 3

fl=php:internal
fn=php::function_exists
330 1

fl=php:internal
fn=php::func


This confuses Webgrind total cost calculation, so that not all functions
are displayed in the profile.

I know that Webgrind is not to blame for Xdebug bugs, but apparently this
bug is hard to track down, so I suggest you provide a workaround until it
has been fixed.

This patch fixes the problem.

Hello, 

Here is the format of my
cachegrind.out.localhost.__phpinfo=1_XDEBUG_PROFILE=true.1216279621

There are '"' in the filename, so I added '=' in the regexp.

So I replace the line 56 of webgrind/config.php :

$outputName = '/^'.preg_replace('/(%[^%])+/', '[a-zA-Z0-9%_-]+',
$outputName).'$/';

by :

$outputName = '/^'.preg_replace('/(%[^%])+/', '[a-zA-Z0-9%_=-]+',
$outputName).'$/';

Regards

Mathieu

I am attaching the patch against the 1.0 version, which allows to hide PHPUnit 
function calls in same way as native PHP functions can be hidden.

After enabling latest release of XDebug 2.1 (http://twitter.com/xdebug/
status/3054234745) on PHP 5.3.0, I found that webgrind did not work
anymore

XDebug configuration

[xdebug]
zend_extension="C:\server\php53\ext\php_xdebug.dll"
xdebug.default_enable = On
xdebug.profiler_enable_trigger=on
xdebug.profiler_enable=on
xdebug.profiler_output_dir="C:\server\php53\xdebug"
xdebug.profiler_output_name timestamp

Webgrind can list a file named cachegrind.out.3740 but it can not
analyze it as usual. No error no warning

Attached generated profile

( copied from mailing list: http://groups.google.com/group/webgrind-
general/browse_thread/thread/8c4d0cbe7c878ed?hl=en )

What steps will reproduce the problem?
1. have a storage dir (/tmp/xdebug) that doesn't exist or is not writable
2. no magic here
3. webgrind mysteriously doesn't pick up xdebug profile updates, and you
get no error message

What is the expected output? What do you see instead?
an error message telling you something is wrong

What version of the product are you using? On what operating system?
1.0, Red Hat

Please provide any additional information below.

I started a patch.  It prints an error message, nothing fancy.  How would
you recommend passing error messages to a errors.phtml?

Thanks.

A field that does live matching against the called functions/methods and 
displays those that match. 
Makes it easy to analyze specific groups, e.g. Zend_Date or database calls only

The templates use shorttags, but not all PHP installations have
php_short_tags setting set to "on". 
Therefor shorttags should be avoided. I made a patch for this against
version 0.5.

We should have a configuration option for displaying time as either micro or 
milliseconds. 
microseconds are a bit difficult to read due to rather large values for many 
applications.

Graphical breakdown not working in IE6. (I hate that browser, hate!)

since the newline in the title of the breakdown box is not valid HTML; it
isn't rendered by my browser either. I suggest the following patch to be
applied. For the bars to remain; the colors should probably be made
transparent.

When data.file=='php:internal' no open file link is shown, which makes
sense. You could however put a link to the PHP manual at the same spot instead.

Bonuspoints for using xdebug.manual_url when available. ;)

Links to fileviewer for where functions are called from does not point to the 
correct file.

ini_get('xdebug.profiler_output_dir') - returns ''.

So I must to edit xdebugOutputDir function's body to replace '/tmp/' on my 
path:
return 'D:/xdebug/';

What if make some default values in Webgrind_Config class definetion (like 
in older versions, like 'defaultHideInternalFunctions' for example)?



WinXP, PHP 5.2.4, xDebug 2.0.3.0

With large files, the display of the source in the built in fileviewer has been 
reported to become 
slow. Attached a suggested patch by Ilya Kondrashov until there is time to 
investigate

Autodetecting will make for even easier installation and free you from updating 
the filename format 
in more than one place.

Get the name with `ini_get('xdebug.profiler_output_name');`  
Possible settings: http://xdebug.org/docs/all_settings#trace_output_name

Shouldn't be too hard.

This is not an issue...
It could be nice to add a button to start kcachegrind (or any similar tool)
directly with the current parsed debug file.

What steps will reproduce the problem?
1. profile a script using smarty template engine
2. open webgrind and search for the include-statement that executes the
compiled template file (has several %s in it's filename)
3. try to "open file"

What is the expected output? What do you see instead?
The listing of the compiled template file should be displayed but most
likely there is an error about "file not found" because some % chars
followed by numbers get resolved to random/weird characters which makes the
filename not existing.

What version of the product are you using? On what operating system?
Webgrind 1.0/PHP 5.2/Ubuntu 8.04 <--> Firefox 3.0.7/MacOSX 10.5.6

Please provide any additional information below.

The fix is pretty trivial. Just escape these chars using encodeURI in
templates/index.phtml in lines 142 and 169. See also attached patch.

0.7 introduced a bug where webgrind could parse the file that is currently 
being generated by 
xdebug, thereby causing an infinite loop.

What steps will reproduce the problem?
1. Load up webgrind and look at drop down on the top.  It is prefixed with
the invokeurl.  I want this to be configurable.  I've supplied a patch to
do this.


The existing code for this is here (in templates/index.phtml, line 271):
<option value="<?php echo $trace['filename']?>"><?php echo
$trace['invokeUrl']?> (<?php echo $trace['filename']?>) [<?php echo
$trace['filesize']?>]</option>

2. What is the expected output? What do you see instead?
Output should be displayed based on format supplied in config.php

What version of the product are you using? On what operating system?
1.0

Please provide any additional information below.
I would like that to be configurable.  The patch file attached provides
this functionality.  The new functionality allows the user to configure
that display with the following options:

%i - invoked url
%f - trace file name
%s - size of trace file
%m - modified time of file name (in dateFormat specified above)

and used like so:

static $traceFileListFormat = '%i (%f) [%s]';

Please let me know if you have any questions or need any changes to it.

Attached is a simple patch that links the functions listed in the 'call
info' slide outs to the full details of those functions.

I find it very handy and it is a very simple change so I thought I'd submit it.

It would be nice if you could open up webgrind with the appropriate report
loaded directly.

I already hacked it in my own installation, it's fairly simple. Using the
document.location.hash property, I only had to change the index.phtml file.
It's attached (is it?)

As a result an URL like this would load my just freshly generated report:

http://localhost/Applications/Webgrind/#cachegrind.out.2910

And creating it with PHP:

<?php
   printf('<hr><a href="/Applications/Webgrind/#%s" target="webgrind">Show
   in Webgrind</a>', basename(xdebug_get_profiler_filename()));
?>

Combining these two related elements results in a faster function_list
action: both loops get faster, less data is json encoded, transmitted and
decoded.

(If you add me as member, I'd be happy to commit this improvement myself)

What steps will reproduce the problem?
1. Create a large cachegrind file

What is the expected output? What do you see instead?
Trying to load a 60MB cachegrind file, my browser got stuck because of the
amount of data returned.

What version of the product are you using? On what operating system?
1.0

Please provide any additional information below.
Perhaps you can process the cachegrind file first, split up the results
into several HTML files and save these. So there would be somekind of
simple cache?

[deleted issue]

What steps will reproduce the problem?
1. I set a profile_log as the output directory for xdebug which is in root 
folder.
2. I set the same location in webgrind config file also
3. I have necessary permissions to read and write into that file
4. Still I dont see any profiles listed in the webgrind dropdown

What is the expected output? What do you see instead?
It should actually show all the profiles in the dropdown. I run one 
website other than webgrind. Profile was getting created in the output 
folder I mentioned for xdebug. But it was not showing up in the profile 
dropdown in webgrind

What version of the product are you using? On what operating system?
Webgrind I am using the latest version and my operating system is windows 
XP. 

What steps will reproduce the problem?
1. I select a cachegrind file with internal PHP functions in it.
2. I click Update.
3. Then I watch the error log.

What is the expected output? What do you see instead?

Expected log output is nothing.

Current warning: [Thu May 22 18:50:29 2008] [error] [client 127.0.0.1] PHP
Notice:  Undefined index:  summary in
/Users/olle/web/webgrind/library/Reader.php on line 200, referer:
http://mylocalweb/webgrind/



What version of the product are you using? On what operating system?

The 0.6 zip. Mac OS X. Apache2. 

Please provide any additional information below.

Something like

    function getHeader($header){
        $headers = $this->getHeaders();
        if (array_key_exists($header, $headers)) {
            return $headers[$header];
        }
        return '';
    }

Might be able to handle it. I added a check for empty-stringness to
formatCost():

        if ($cost==='') {
          $cost = 0;
        }

(Sorry about the non-patchy nature of this, but... where is the SVN repo? :-) )

What steps will reproduce the problem?
The current relase of webgrind (0.9) has no updated changelog. Latest entry
is for 0.81

What version of the product are you using? On what operating system?
0.9

v0.71

If line has very big width right <code> block (with source) drops down, 
but not float to left <code> block (with lines numbers).

Please, use table instand float block ^___^

What steps will reproduce the problem?
1. Use ...%R.%s... in xdebug.profiler_output_name on Windows
2. Name a directory something like 'example.com'
3.

What is the expected output? What do you see instead?
Expected to see files such as:
cachegrind.out..example.com/index.php.###_### in popup.

%R is "not working" for me.  Posted to xdebug-general, but for now...

No such files were there.

What version of the product are you using? On what operating system?
Everything current on xdebug/webgrind/xdebug-helper
Windows XP sp 2.

Please provide any additional information below.
Patch:
--- config.php.original 2008-07-23 11:36:10.103817300 -0500
+++ config.php  2008-07-23 11:35:27.885067300 -0500
@@ -53,7 +53,8 @@
                if($outputName=='') // Ini value not defined
                        $outputName = '/^cachegrind\.out\.[0-9]+$/';
                else
-               $outputName = '/^'.preg_replace('/(%[^%])+/',
'[a-zA-Z0-9%_-]+', $outputName).'$/';
+               $outputName = '/^'.preg_replace('/(%[^%])+/',
'[a-zA-Z0-9%_.-]*', $outputName).'$/';
            return $outputName;
     }


Feel free to accept ONLY the change from + to * or ONLY the addition of '.'
in the replacement character set.

I guess I should have made it two different patches, since it's two
different issues, technically...

Sorry.

Hey, at least I'm providing patches, eh?

Line numbers should start from 1, not 0

the current outputname is determined as follows:
$outputName = '/^'.preg_replace('/(%[^%])+/', '[a-zA-Z0-9%_-~=]+',
$outputName).'$/';

However; this is far too restrictive; my xdebug.profiler_output_name is set
to 'profile.%R'; which means that the filename can include all characters
that are allowed in a URL; such as ~ and =. I suggest changing the match to
simply .

What steps will reproduce the problem?
Use Windows or new version of XDebug or different configuration of XDebug
or whatever formats XDebug with:

\n
==== NEW PROFILING FILE =====...===\n
version: 0.9.6\n
cmd: /full/path/here\n

What is the expected output? What do you see instead?
The popup for the grind files is bad, with NEW PROFILE FILE ====== instead
of the actual invokeUrl.

There's a TODO comment about this in ~/library/FileHandler.php actually.

What version of the product are you using? On what operating system?
current and Windows XP sp2.

Please provide any additional information below.
Patch:
--- FileHandler.php.original    2008-07-23 09:49:53.603817300 -0500
+++ FileHandler.php     2008-07-23 10:00:08.135067300 -0500
@@ -51,12 +51,17 @@
         * @return void string
         */
        private function getInvokeUrl($file){
+               if (preg_match('/.webgrind$/', $file)) return 'Binary!';
                // Grab name of invoked file.
-               // TODO: Makes assumptions about where the "cmd"-header is
in a trace file. Not so cool, but a fast way to do it.
-           $fp = fopen($file, 'r');
-           fgets($fp);
-           $invokeUrl = trim(substr(fgets($fp), 5));
-           fclose($fp);
+               $fp = fopen($file, 'r');
+               $invokeUrl = '';
+               while ((($line = fgets($fp)) !== FALSE) &&
!strlen($invokeUrl)){
+                       if (preg_match('/^cmd: (.*)$/', $line, $parts)){
+                               $invokeUrl = isset($parts[1]) ? $parts[1] : '';
+                       }
+               }
+               fclose($fp);
+               if (!strlen($invokeUrl)) $invokeUrl = 'Unknown!';
                return $invokeUrl;
        }

@@ -130,4 +135,4 @@
                return ($a['mtime'] > $b['mtime']) ? -1 : 1;
        }

-}
\ No newline at end of file
+}

What steps will reproduce the problem?

1. Installed Xdebug ok, and configured to generate cachegrind files to
public writeable directory nominated in php.ini under
xdebug.profiler_output_dir (always with web server restart)

2. Invoking webgrind without further configuration shows no files to select.

3. Have alternatively tried man different writable directories, both
outside web root and under /webgrind/ folder within web server.

What is the expected output? Cachegrind files to select above "Select a
cachegrind file above"

What do you see instead? Just "Select a cachegrind file above", no files
(although cachegrind files definitely generated ok into expected directory).

What version of the product are you using? On what operating system?

Webgrind 1.0
Mac OS X Leopard 10.5.4
PHP 5.2.12

Please provide any additional information below.

I also tried strategies recommended here:

http://anantgarg.com/2009/03/10/php-xdebug-webgrind-installation/

Explicit paths in webgrind config.ini:

  static $storageDir = '/Library/WebServer/Documents/webgrind/tmp';
  static $profilerDir = '/Library/WebServer/Documents/webgrind/tmp';

(note on Mac OS X Leopard /tmp is private to root).

Added an .htaccess in the webgrind folder with the following contents

php_flag xdebug.profiler_enable 

Did not seem to help.

What steps will reproduce the problem?
1. Open the index page

What version of the product are you using? On what operating system?
Webgrind v1.0, RHEL

Profiler output files can have very long names. I use the
cachegrind.out.%R.%p format which creates lengthy file names. The "options"
div floats to the right of the browser window, so the biggest part of
filenames in the "dataFile" dropdown is invisible.

Proposed solution:
Make the "options" div float-left and the "logo" div float-right in
/styles/style.css

What steps will reproduce the problem?
1. Anything like " fn=require::F:\My Documents\My
Web\running_local\system\class\user.php " in the cahcegrind file.
2.
3.

What is the expected output? What do you see instead?
I would expect the entire filename to make it into the function name. 
Otherwise all of the require statements get lumped together.

What version of the product are you using? On what operating system?
1.0
Windows XP, Apache 2.2, PHP 5.2.6

Please provide any additional information below.
The issue here is the line:
http://code.google.com/p/webgrind/source/browse/trunk/library/Preprocessor.php#6
4

This line is using %s to get the string and this seems to be balking at the
spaces.  This can be fixed by doing the following:

list($function) = fscanf($in,"fn=%[a-zA-Z0-9,. _:\>%^{}-]");

Note that I have included all the odd punctuations because they appear in
my file names.  Not sure if there is a performance penalty for this, but it
generates the correct result.

As requested by Bharat Mediratta:

"Hey Joakim.  Thanks again for webgrind, it is very useful.  I'm using it to 
optimize Gallery3 and 
one of my most common operations is to make a change and try to predict then 
demonstrate a 
performance delta.  The way I do it now is that I do a couple of 
?XDEBUG_PROFILE runs before 
and after my change, then open them all up in tabs in Chrome and switch back 
and forth 
between the two to compare numbers.

What would help me there would be a way to figure out the delta between two 
runs so that I 
could get an idea of the impact of a change.  Eg, it would be very nice to know 
that function foo() 
took up 10% of my total request processing time before and 7% afterwards.

As a bonus if I could aggregate a set of runs and label them, then compare 
between labels I 
could use the aggregation to reduce the noise between multiple runs.  Simple 
aggregation that 
just took the average would be a fine start although in a perfect world I could 
do 10 runs and it 
would drop the outliers.

Not a trivial request, I'm sure.  Thanks for your consideration!"

What steps will reproduce the problem?
1. Unfold a white function row with more than one invocation

There is not zebra-stripes

Since the revision 124, I have a javascript error in firefox3.

http://code.google.com/p/webgrind/source/diff?old=122&r=125&format=side&path=%2F
trunk%2Ftemplates%2Ffileviewer.phtml

When xdebug appends profiles, the 'cmd' part of the headers might not display 
the correct 
invokeUrl. Since it is possible to profile completely different scripts, it 
should say 'Multiple files' in 
such case.

Webgrind should fail gracefully if the function json_encode does not exist

http://dk.php.net/json_encode

Provide a method for checking for new version

when I upgrade I normally copy all of the files except config.php since
this is where I have my personal config.

But the has the effect that my version number shown is 0.9.

I think the version number should be move out of config.php

Perhaps it should be possible for the Webgrind_Configclass to have to
default values and then have config.php override the Webgrind_Config class.
in true object style :)

Replace line 41 :

            <? endforeach;

by 

            <?php endforeach;

Regards

Mathieu

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Generate a humungous cachegrind file
2. Choose it from the popup list without realizing it
3. Wait forever

If would be Really Nifty (tm) if the popup list could also contain the file
size.

Patch from 0.81 attached, but it also contains other patches I posted before...

Sorry about that...