-
Notifications
You must be signed in to change notification settings - Fork 88
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
memory_profiler reporting itself #49
Comments
I think you may have mixed the .start/.stop mode with the .report mode in your IRB session. I can recreate memory_profiler self-reporting by calling
Please re-open this issue if can recreate the problem in a clean IRB session or a script. |
BTW @dgynn unless GitHub has changed how it works, issue creators can't re-open issues that a contributor has closed. |
Thanks @seanlinsley I didn't realize that. |
@dgynn it's a 100% not due to me calling
But it's a little spurious , I'll try creating a more consistent testcase. |
@ohaddahan Oh, here's a possible cause. If the block of code being reported on throws an exception we are not cleaning up correctly.
Is it possible that happened in your IRB session? That is something we should handle better. |
@dgynn might be it , I'll give a try. Sounds possible since ctrl+C is quite common during interactive debug session :) |
I noticed today (I also updated my Gems today , so it might be related).
That memory_profiler now reports it's own footprint as a part of the analysis report.
I believe this wasn't the case before and it creates a false top level analysis metrics.
See the example here:
https://gist.github.com/ohaddahan/cdaef533abf963f16f7bccec141c2185
Most of the memory report is actually caused by memory_profiler.
The text was updated successfully, but these errors were encountered: