search

pharo-spec / NewTools

All development tools for Pharo, developed with Spec
21 stars 54 forks source link

"Run To" command in Debugger is incredibly slow #847

Closed daniels220 closed 1 month ago

daniels220 commented 1 month ago

Trying to use "run to" to execute what should be maybe a few hundred message sends, but as part of a to:do: loop so they are all in the same context, takes...far too long, I don't actually know how long, I stopped it after a minute or so. When I interrupted it with Ctrl+. I see that it is trying to update the debugger for each step along the way, due to just repeatedly invoking the "Step Over" command, which triggers an event that causes updates.

As a hack, I tried disabling event triggers altogether (by stashing and clearing the actionMap) during the loop that calls stepOver:, then re-enabling and triggering one #stepOver event at the end, and this sped things up tremendously.

I can think of two possible solutions:

  1. Effectively inline the implementation of stepOver: and remove the triggers along the way, doing just one at the end. Perhaps with some refactoring this could be a good option, but when I tried it I ran into some subtle issues with keeping track of the frame the command was issued in vs. the frame we're actually currently stepping in.
  2. Set a flag on the debugger that we are in the middle of a composite operation so those events are ignored and we update once at the end. This might be useful for other advanced step options as well.
StevenCostiou commented 1 month ago

Thank you for raising the issue. There is already a mechanism in the debugger to actually avoid updating after each action on the debug session. It is used, I think, in the implementation of similar commands in the advanced menu.

I will have a look at that friday during the sprint. Would you have a reproducible case of slow scenario that I could use for testing?

daniels220 commented 1 month ago

Oh! The mechanism you mention is new since Pharo 11, which I am still using. Good to know this has been fixed, I guess!

On a related note, when various Pharo components were broken out into separate Github repositories, the issue templates ("Bug Report", "New Feature", "Enhancement" etc) didn't get copied—if they had, you would have seen my Pharo version in the initial report. Might be good to do that...

StevenCostiou commented 1 month ago

Have you tested your scenario with Pharo 12 ? Is it better there?

daniels220 commented 1 month ago

Yes, it's definitely fixed in Pharo 12. I went looking for the mechanism you mentioned in Pharo 11, didn't find it, went, "wait, I wonder", looked in Pharo 12, the mechanism is indeed very obvious, tried a test scenario and it's basically instant as it should be where in P11 it takes a minute+.