-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigating the debugger stack is super slow #584
Comments
One thing that could be a reason (for sure not the only one): allInspectorNodes add a "self" node:
this then is used in StInspectorNode>>#children, while the debugger even filters it out again in some cases: StDebuggerContext>>#receiverNodes
For speed, this just doubles the amount of nodes that are created... |
Regarding this, the debugger rejects the self node by default and adds one whose host object is the receiver of the home context. |
This is due to selection remembering in the inspector: if we select a variable in the inspector, then change context in the stack and then go back to the first context where we selected that variable, the debugger remembers the selection and reactivates it again.
Disabling this mechanism makes the stack navigation much much faster and agreeable for users.
All the time is spent in the miller list presenter, where doing
selectIndex:
to select the remembered selection goes into a whole announcement and widget updating procedure.More analysis to come.
I suspect that part of the slowness of the debugger comes from that (in general, whenever there is a miller list update).
The text was updated successfully, but these errors were encountered: