Code review comment for lp:~kbielefe/bzr/551391-log-memory-usage
Revision history for this message
| Karl Bielefeldt (kbielefe) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
> If we just ran out of memory, maybe meliae.
> appropriate?
You're probably right. The way I tested it, it failed allocating one last big chunk, so it still had enough memory to build the set. However, I think the allocation that caused it to fail wouldn't show up in the dump anyway because it never existed. The stack trace would be more useful in that case.
Where a memory dump on MemoryError is really useful is when you have a slower accumulation of too many smaller objects, and an approximation is probably good enough for those purposes. Maybe a fallback from dump_all_objects to dump_gc_objects would be useful?
When you want the precision is while doing memory profiling for development, and then developers can use whichever method works best for their scenario.
It just occurred to me that since I'm fixing the PQM bugs anyway, if it would be useful to add a hidden command like "bzr decode-memdump /tmp/dumpfile.json" for printing the summary information. That would make it a lot easier for an end user to file a bug report.