Skip to content

memory_profiler reporting itself #49

Description

@aiman2039

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.


Total allocated: 28693134 bytes (206218 objects)
Total retained:  28671354 bytes (205866 objects)

allocated memory by gem
-----------------------------------
  28664857  memory_profiler-0.9.8
     26437  chili-hunter-2/app
      1840  activesupport-5.0.0

Activity

  1. dgynn commented on Sep 25, 2017

    @dgynn
    Collaborator

    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 MemoryProfiler.start first. I expect that your IRB session got into a weird state this way.

    MemoryProfiler.start
    MemoryProfiler.report { "allocate one string" }.pretty_print
    
    Total allocated: 1496 bytes (10 objects)
    Total retained:  232 bytes (1 objects)
    
    allocated memory by gem
    -----------------------------------
          1456  memory_profiler/lib
            40  other
    ...
    

    Please re-open this issue if can recreate the problem in a clean IRB session or a script.

  2. seanlinsley commented on Sep 25, 2017

    @seanlinsley

    BTW @dgynn unless GitHub has changed how it works, issue creators can't re-open issues that a contributor has closed.

  3. dgynn commented on Sep 25, 2017

    @dgynn
    Collaborator

    Thanks @seanlinsley I didn't realize that.

  4. aiman2039 commented on Sep 25, 2017

    @aiman2039
    Author

    @dgynn it's a 100% not due to me calling MemoryProfiler.start since I never use that and always opt for :

    report = MemoryProfiler.report do
    ......
      end 
      report.pretty_print( to_file: 'file.txt' )
    

    But it's a little spurious , I'll try creating a more consistent testcase.

  5. dgynn commented on Sep 25, 2017

    @dgynn
    Collaborator

    @ohaddahan Oh, here's a possible cause. If the block of code being reported on throws an exception we are not cleaning up correctly.

    MemoryProfiler.report { raise "error" } rescue nil
    MemoryProfiler.report { "allocate one string" }.pretty_print
    
    Total allocated: 1496 bytes (10 objects)
    Total retained:  232 bytes (1 objects)
    
    allocated memory by gem
    -----------------------------------
          1456  memory_profiler/lib
            40  other
    

    Is it possible that happened in your IRB session? That is something we should handle better.

  6. reopened this on Sep 25, 2017
  7. aiman2039 commented on Sep 25, 2017

    @aiman2039
    Author

    @dgynn might be it , I'll give a try. Sounds possible since ctrl+C is quite common during interactive debug session :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions