... | ... | @@ -14,3 +14,17 @@ Related issue: #8837. |
|
|
* (2013) [From the creator of memory_profiler ](http://fa.bianp.net/blog/2013/different-ways-to-get-memory-consumption-or-lessons-learned-from-memory_profiler/), resource is a bit faster than psutil, but possibly less accurate. Spawning `ps` is some orders of magnitude slower.
|
|
|
* (2014) In a [comment about memory_profiler](http://www.marinamele.com/7-tips-to-time-python-scripts-and-control-memory-and-cpu-usage), this person says 2 important things: (1) that memory_profiler is faster if psutil is installed, and (2) that measuring memory influences time. *Maybe tests that measure memory and cpu should be run separatelly from tests that measure time.*
|
|
|
* [This person says that](http://www.marinamele.com/7-tips-to-time-python-scripts-and-control-memory-and-cpu-usage) "[memory_profiler] is extremelly useful if you're wanting to profile a section of memory-intensive code, but it won't help much if you have no idea where the biggest memory usage is. In that case, a higher-level approach of profiling is needed first". Also, "memory_profiler comes with a script called *mprof*, which can show you memory usage over the lifetime of your application. This can be useful if you want to see if your memory is getting cleaned up and released periodically".
|
|
|
|
|
|
## Scenarios
|
|
|
|
|
|
Depending on the resource and accuracy, different scenarios might make more sense:
|
|
|
|
|
|
* for measuring time:
|
|
|
* running in bare metal and queued helps allocate all/most resources to intended task.
|
|
|
* cpu and i/o (disk, network) speed make a lot of difference.
|
|
|
* resources external to the measured program should ideally be run on other environments.
|
|
|
* network access affects output.
|
|
|
* for measuring memory:
|
|
|
* virtualized environments are less of a problem.
|
|
|
* granularity impacts time.
|
|
|
* granularity impacts how measurement is made. |
|
|
\ No newline at end of file |