MemoryProfiler VS stackprof

Wire the memory_profiler into an around_action to identify your bloaty actions.

The memory_profiler gem offers a very simple API and a detailed (albeit a little overwhelming) allocated and retained memory report — that includes the classes of objects that are allocated, their size, and where they were allocated. It's straightforward to add to our leaky program.

memory_profiler

We don't need to rely upon a priori reasoning only, we can use memory_profiles and benchmark_ips to compare the memory consumption and iterations per second of each solution.

Either https://github.com/tmm1/stackprof for cpu or https://github.com/SamSaffron/memory_profiler for memory. In practice profiling and removing allocations also gives a large perf boost.

Our project has one endpoint which gets called quite often. So, I profiled it with memory profiler and saw a line pointing to hstore.rb.

stackprof can be used alone/by itself to generate flamegraphs for arbitrary Ruby code.

I’d use something like stackprof ( https://github.com/tmm1/stackprof ) to see where the time is going. If you already have suspicions you can use it to get information about a specific method / few lines of Ruby but there’s also a rack middleware.

stackprof

Other profilers, such as stackprof, trace everything that’s happening by line. These types of profilers usually need some instrumentation to be configured, as shown below:

Either https://github.com/tmm1/stackprof for cpu or https://github.com/SamSaffron/memory_profiler for memory. In practice profiling and removing allocations also gives a large perf boost.

At first, I tried to benchmark the method using the benchmark library. (The profiler uses stackprof)