Add Memory support#1
Conversation
Easier to read / maintian this way.
Xdebug has supported memory for a while, but this tool hadn't been updated to use it. Here we add a new "costFormat" option of "bytes of memory". We pass this through to the pre-processor to have it read the memory cost field instead of the time cost field.
Just like the PHP pre-processor, we read the memory if costFormat == 'bytes'.
| static function parse($inFile, $outFile) | ||
| static function parse($inFile, $outFile, $readMemory = false) | ||
| { | ||
| $costPattern = $readMemory ? "%*d %d" : "%d"; |
There was a problem hiding this comment.
Could you explain the reason for this pattern?
The %*d is skipping the number correct?
What number is in the second / third positions?
There was a problem hiding this comment.
Yes, every "cost line" looks like this:
4 936 160 == {line number} {time cost in usec} {memory cost in bytes}
When we want to read memory, we effectively need to skip the time cost and read the last number (which is normally unread).
| $readMemory = $costFormat === 'bytes'; | ||
| $memorySuffix = $readMemory ? ".memory" : ""; | ||
| $prepFile = Webgrind_Config::storageDir().$file.$memorySuffix.Webgrind_Config::$preprocessedSuffix; | ||
| try { | ||
| $r = new Webgrind_Reader($prepFile, $costFormat); | ||
| } catch (Exception $e) { | ||
| // Preprocessed file does not exist or other error | ||
| Webgrind_Preprocessor::parse(Webgrind_Config::xdebugOutputDir().$file, $prepFile); | ||
| Webgrind_Preprocessor::parse(Webgrind_Config::xdebugOutputDir().$file, $prepFile, $readMemory); |
There was a problem hiding this comment.
Ah! Cool, you are creating two pre-processed files (one for memory, one for CPU)
|
QA 💎 - Webgrind now receives and presents memory information.
If this is alright, then please disregard the deploy block. |
|
I made a minimal example and the data is coming out correct in both tools for me. Actually, it appears that <?
function main() {
$x[] = useMemory(100);
$x[] = useMemory(1000);
$x[] = useMemory(10000);
$x[] = useMemory(100000);
$x[] = useMemory(1000000);
$x[] = useMemory(10000000);
}
function useMemory(int $bytes) {
return str_repeat("x", $bytes);
}
main();Note that
|
|
Nah, it seems like it's a bug in Here's a slightly more complex example: function main() {
$x[] = use10KB();
$x[] = use1MB();
}
function use1MB() {
$overhead = useMemory(100);
return useMemory(10000000);
}
function use10KB() {
$overhead = useMemory(100);
return useMemory(10000);
}
function useMemory(int $bytes) {
return str_repeat("x", $bytes);
}
main();
|
|
@jarstelfox recommended I change "main" to something else. No dice,
|
|
dev_block 👍 the binary pre-processor is producing the wrong results. |
|
I do wish there was some test suite here.
looks like you found a bug |
Some other pull upgraded jQuery and that caused this jQuery plugin to crash. Stubbing this "browser" object will allow expressions like "$.browser.ie" to return undefined instead of throwing.
Previously, the tablesorter was detecting numeric values with thousands separators as "text" and sorting them incorrectly. I added thousands separators for bytes values, so they are easier to read at a glance as the numbers get long but the sorter hadn't been parsing them well. Note: I'm not sure why the "Cost" column was set to "sorter: false" on the subtables, it had still been sorting but it had been falling back to auto-detecting the sort type.
|
un_dev_block 👍 The outputs are the same, it was a sorting type auto-detection issue. |
kthaler
added
QAing
|
QA 💎 - The bytes of memory cost option in webgrind is displaying correct values. un_deploy_block 🦕 - Fixed the problem with my qcachegrind and it is now showing the same/similar values as webgrind. |
4 participants
Support retrieving and using the memory information that XDebug records.
Adding "memory" as cost format option was the easiest way to get it done.