-
Notifications
You must be signed in to change notification settings - Fork 712
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
Flame Graph #440
Flame Graph #440
Conversation
Fix Crossgen symbol lookup.
ID. The newest value wins.
…oseTraceData to reflect MethodLoadUnloadVerbose_V2 manifest
HistoryDictionary: Replace manually sorted list with SortedDictionary
…osoft-Windows-DotNETRuntime/Method/LoadVerbose events
Update MethodLoadUnloadVerboseTraceData to reflect MethodLoadUnloadVerbose_V2 manifest
Include Microsoft.Diagnostics.FastSerialization in the TraceEvent package
This is missing and is an essential part of the package.
Tell people how to build without using Visual Studio IDE.
Add the OSExtentions DLL to the TraceEvent Nuget package
When parsing timestamp of an event ("0.0") with the current culture set to "fr-FR", a System.FormatException is raised.
When parsing timestamp of an event ("0.0") with the current culture set to "fr-FR", a System.FormatException is raised.
…die/perfview into FixLinuxEventTracingTests
This member is needed to parse events in a high performance way (no copying) It was protected because the common scenario is to use this in TraceEvent subclasses but it can be useful for ad-hoc pointer based parsing, so we are making it public.
Make The DataStart property public
Fix LinuxPerfScriptEventParser when parsing timespamp event
Use the codecov uploader from NuGet
…g\TraceProcess sets these fields is via the tracelog. This portion of the code (as it transitions to a source based model) does not have access to the right information. The *RelativeMsec data is stored as the process is inspected on events.
The documentation implied that you only had to match one IncPat for a sample to be included, which isn't correct. This was particularly confusing since the documentation continued discussing an OR operator.
Remove TraceEventNativeMethods.ZeroMemory
Added the Gen 2 object Deaths view for 100K Sampling
Improve the performance of CallTreeNode.AllCallees
Improve debugging experience by omitting children from Node.ToString()
Clarify documentation for IncPats
We need to install a .NET Profiler via the registry for some PerfView operations. We were not being agressive enough to clean up even, if things are partly wrong. This can leave stale state behind. This improves the robustness.
Fix logic that touches registry to be very robust
Fix Linux NGEN/R2R symbols
Codecov Report
@@ Coverage Diff @@
## master #440 +/- ##
==========================================
- Coverage 17.54% 17.52% -0.02%
==========================================
Files 213 214 +1
Lines 122889 123027 +138
Branches 11839 11855 +16
==========================================
+ Hits 21555 21562 +7
- Misses 100475 100606 +131
Partials 859 859
Continue to review full report at Codecov.
|
1 similar comment
Codecov Report
@@ Coverage Diff @@
## master #440 +/- ##
==========================================
- Coverage 17.54% 17.52% -0.02%
==========================================
Files 213 214 +1
Lines 122889 123027 +138
Branches 11839 11855 +16
==========================================
+ Hits 21555 21562 +7
- Misses 100475 100606 +131
Partials 859 859
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #440 +/- ##
==========================================
- Coverage 17.57% 17.52% -0.05%
==========================================
Files 216 214 -2
Lines 123202 123027 -175
Branches 11879 11855 -24
==========================================
- Hits 21654 21562 -92
+ Misses 100684 100606 -78
+ Partials 864 859 -5
Continue to review full report at Codecov.
|
I love this! I know it will help a lot of users figure out at a glance what’s happening in their call tree. Would the folding and grouping from the tree view be applied to the flame graph as well? Finally in terms of the palette, it might make sense to use a default palette for .NET processes where the .NET frames, CLR frames, Windows library frames, and kernel frames are colored using different palettes. (Like the flamegraph.pl Java palette, for example.) +100000 |
@goldshtn yes, I am reusing the data generated for the call tree, so I get all of it's advantages out of the box tutorial.exe with default grouping: tutorial.exe with no grouping |
@goldshtn I really like this idea, but I have not found a way to implement it yet. My problem is that based on the name of the method I currently can not say to which group it belongs (it is just a string). I need to dig into the code of PerfView and do some PoC. Maybe I could use the existing grouping regexes to do it? It looks like perfect candidate |
@adamsitnik Wait, if you're reusing same call tree, then all grouping is already done for you. So maybe all CLR calls are already grouped into "CLR" nodes. So, I would suggest to start with highlighting different folded groups with different palettes - it will already give nice visual understanding of how these groups are distributed. |
due to some problems with GIT I need to recreate my fork. Flame graphs will be back ;) |
Recreated #502 |
PerfView is very powerful tool, but sometimes for some inexperienced users like me it is hard to get a fast overview of what takes most of the CPU if there are plenty of methods on the stack.
This PR provides a simple implementation of the "Flame Graph".
It is just different visualization of the "call tree" view.
Sample result (for the "tutorial.exe")
Sample result for more complicated app (dotnet cli):