feat: initial work on profiling #392
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR implements basic .cpuprofile capturing for debug sessions. - Users can start profiling through a context menu on the debug session, or by running a command from the palette. If there's more than one session, running a command will open a quickpick to choose the session to profile. - They will then be asked what kind of profile they want to record. For Node.js this will be .cpuprofiles and .heapprofiles. For browsers, it will allow the newer trace profiles. - While profiling, the debugger is disabled, like the chrome devtools does. This removes performance overhead and the ability to hit breakpoints, which mess with the profile... - Profiling state is shown in the status bar, and clicking on the entry will stop profiling and ask the user where they want to save the profile file. There's also a 'stop profiling' command. This should give us a good foundation for further types and profiling mechanics in the future. I'm not totally happy with the entry and exitpoints as-is. You have to know it's there to be able to start profiling, and then it's kind of hard to figure out how to stop profiling. The chrome devtools shows an overlay while profiling, which prevents the user try to e.g. set breakpoints or use the REPL, implicitly communicating that debugging is not possible in this state. I'm not sure what the best solution for us is. cc @roblourens @ididorn for thoughts. Will also bring this/whatever we discuss up in next week's UX sync.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements basic .cpuprofile capturing for debug sessions.
or by running a command from the palette. If there's more than one
session, running a command will open a quickpick to choose the session
to profile.
Node.js this will be .cpuprofiles and .heapprofiles. For browsers, it
will allow the newer trace profiles.
does. This removes performance overhead and the ability to hit
breakpoints, which mess with the profile...
will stop profiling and ask the user where they want to save the profile
file. There's also a 'stop profiling' command.
This should give us a good foundation for further types and profiling
mechanics in the future.
I'm not totally happy with the entry and exitpoints as-is. You have to
know it's there to be able to start profiling, and then it's kind of
hard to figure out how to stop profiling. The chrome devtools shows an
overlay while profiling, which prevents the user try to e.g. set
breakpoints or use the REPL, implicitly communicating that debugging is
not possible in this state. I'm not sure what the best solution for us
is.
https://memes.peet.io/img/20-03-1ac56131-ddd4-47f7-9eb1-10644db126f4.webm
cc @roblourens @ididorn for thoughts. Will also bring this/whatever we
discuss up in next week's UX sync.