We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
My internal concept of this tool comes from the .Net CLR Profiler I used to use ten years ago. Here is a description from MSDN Magazine.
The old CLR code is here
The Sankey view of which objects are retaining which other objects is (I think) just what you need when you can't figure out why the heap is so large.
The viewcore program seems a great place to start, though it needs some updating for Go 1.16 golang/debug#7 and golang/debug#5
The text was updated successfully, but these errors were encountered:
view of which objects are retaining which other objects is (I think) just what you need when you can't figure out why the heap is so large
Let me know if you ever build something like this :) Currently trying to get some use out of viewcore, but like you say, it's a bit outdated.
Sorry, something went wrong.
Over Xmas I tried to get viewcore more up-to-date: golang/debug@master...bboreham:go-debug:go-1-20
Unfortunately Go 1.22 moved it further away again.
No branches or pull requests
My internal concept of this tool comes from the .Net CLR Profiler I used to use ten years ago.
Here is a description from MSDN Magazine.
The old CLR code is here
The Sankey view of which objects are retaining which other objects is (I think) just what you need when you can't figure out why the heap is so large.
The viewcore program seems a great place to start, though it needs some updating for Go 1.16 golang/debug#7 and golang/debug#5
The text was updated successfully, but these errors were encountered: