View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001757XdebugStep Debuggingpublic2020-03-05 17:542020-11-12 16:15
Reporterbarel Assigned Toderick  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version3.0.0beta1 
Target Version3.0.0RC1Fixed in Version3.0.0RC1 
Summary0001757: Pause-execution feature degrades performance
Description

Today I updated to the latest master from commit 74e462ca201384b4da426bca147a8a9b5c7e5ef7

Running this php code:



<?php

function fib($n)

{

if ($n <= 1) {

return 1;

}

return fib($n - 1) + fib($n - 2);

}


echo fib(35);

The time to run it changed from 2:16 min to 7m52s

Steps To Reproduce

Get the latest master (commit 77ab59507e7a6bd07a50bd667a4c218160d66b83) and run the php code above. Compare the execution time with the time you obtain with commit 74e462ca201384b4da426bca147a8a9b5c7e5ef7. You will find that the execution time is much worse

Additional Information

This seems to be related to the changes in this PR https://github.com/xdebug/xdebug/pull/477 I suggest you test the implications of this code in the general performance of XDebug before adding this to a generally available release

Tagsperformance
Operating System
PHP Version7.1.20-7.1.24

Activities

barel

2020-03-06 06:10

reporter   ~0005272

Last edited: 2020-03-06 12:55

The degradation in performance is due to calling xdebug_dbgp_cmdloop on every statement. Doing i/o on every statement is going to reduce the performance I think that the "Support for pause-execution" feature needs to be re-thought

derick

2020-03-06 12:30

administrator   ~0005278

Please refer from using superlatives in issues, such as "terrible" and "clearly a bad idea". There is another person on the end of these comments.

The link to the commit that you're mentioning is https://github.com/xdebug/xdebug/commit/9efaf95844e5e0fb08c29d6a698eb1fadaf47aae

Your script does 35 billion function calls, which I don't quite consider a normal use case, but I do see your point. I don't even think it makes sense to see whether there is an incoming "break" command at every function call either. The resolution of people pressing (as an example) "Ctrl-C" to initiate the break isn't in the order of microseconds anyway. It would make more sense to check this for example every second only, however, that makes the feature non-deterministic and hence, hard to test reliably.

derick

2020-11-12 14:38

administrator   ~0005520

FWIW, I agree. It's not worth the overhead or the extra maintenance. I'm in the process of removing this 'feature'.

derick

2020-11-12 16:15

administrator   ~0005522

Last edited: 2020-11-12 16:15

I've reverted the inclusion of 0001016, pause-execution.

Issue History

Date Modified Username Field Change
2020-03-05 17:54 barel New Issue
2020-03-05 17:54 barel Tag Attached: performance
2020-03-06 06:10 barel Note Added: 0005272
2020-03-06 12:30 derick Note Added: 0005278
2020-03-06 12:31 derick Summary The performance of the latest version is terrible => Pause-execution feature degrades performance
2020-03-06 12:31 derick Description Updated
2020-03-06 12:31 derick Target Version => 3.0dev
2020-03-06 12:55 derick Note Edited: 0005272
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:37 derick Category Variable Display => Step Debugging
2020-11-12 14:38 derick Status new => confirmed
2020-11-12 14:38 derick Product Version 2.9.2 => 3.0.0beta1
2020-11-12 14:38 derick Target Version 3.0dev => 3.0.0RC1
2020-11-12 14:38 derick Note Added: 0005520
2020-11-12 16:15 derick Assigned To => derick
2020-11-12 16:15 derick Status confirmed => closed
2020-11-12 16:15 derick Resolution open => fixed
2020-11-12 16:15 derick Fixed in Version => 3.0.0RC1
2020-11-12 16:15 derick Note Added: 0005522
2020-11-12 16:15 derick Note Edited: 0005522