Skip to content
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

Performance problem, when a lot of local variables. #35

Closed
onor13 opened this issue Feb 10, 2017 · 2 comments
Closed

Performance problem, when a lot of local variables. #35

onor13 opened this issue Feb 10, 2017 · 2 comments

Comments

@onor13
Copy link

onor13 commented Feb 10, 2017

Hello, the debugger I am implementing must deal with up to 3 000 local variables, sometimes even more. Each variable is an object containing some information that will be displayed in the Visual Studio « Locals » window. So my Expression Compiler generate the PE, as described here https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/CLR-Expression-Evaluators, containing up to 3 000 methods (1 for each variable), where each of this methods returns a custom object. The problem is when the debugger enters IDkmClrResultProvider.GetResult method, all the 3000 methods from PE are already evaluated, which takes a lot of time for some reason. I noticed that the debugger spends about 12-15 seconds (on my Intel-i7 laptop) between the end of IDkmClrExpressionCompiler.GetClrLocalVariableQuery method and the start of IDkmClrResultProvider.GetResult method on every Debug Step Over. Is it possible to make this evaluation lazy? Because the list of the variables is so long, in the Visual Studio locals windows they are not all visible at once, the user has to Scroll Down/Up to see the rest of the variables. Similar lazy evaluation already exists when displaying arrays in the IDkmClrResultProvider.GetItems(DkmEvaluationResultEnumContext enumContext, DkmWorkList workList, int startIndex, int count, DkmCompletionRoutine completionRoutine) method, where only the COUNT number of variables are displayed. Is there anything I can do, like implementing some additional interfaces in order to improve the performance of the debugger?

Vladimir.

@kelltrick
Copy link

@plnelson, we always evaluate all locals in scope, or is that something that can be controlled?

@plnelson
Copy link
Member

I haven't investigated. However, both Concord and AD7 APIs support getting partial lists of locals so presumably the UI is asking for all locals at once. Seems reasonable to get all locals at once to avoid round trips between local/remote though this won't work too well if there are thousands of locals :-)

@onor13 onor13 closed this as completed Mar 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants