The CPU profiling release

Next major release with CPU profiling

The next major release of rbkit will feature proper CPU profiling support and fine tune/optimize memory profiling.

This Wiki is a rough spec of changes for next release. We are creating tickets in github issues to track items from here.

General Core enhancement

• Sometimes sending a really large profiling dump is not possible and hence a message must be split by the Server and processed correctly by the client.
• We need more fine tuned way of turning on traces and turning off traces. This should be possible at anytime during lifetime of ruby application.
• Even when traces are on a client may choose to not receive events for those traces. For example, object traces may be on, but client may not care about receiving live object creation and deletion events. This should be supported.
• It should be possible to turn on and off, all data client receives.

Memory profiling enhancement

• I am thinking parents of an object can be displayed inline by turning the node with filenames into expandable. In fact, the every node can be drilled down without opening new tabs. This seems like more user friendly way of doing things. It is bit difficult to implement it though, but I think it should be possible.

General Desktop app enhancements

• The desktop app has to have its UI redesigned to support memory and cpu profiling. The toolbar may get cluttered because of too many buttons etc. I am thinking, we should try and use Ribbon UI (http://www.devmachines.com/qtitanribbon-overview.html) to streamline the toolbar.

CPU profiling enhancements for Rbkit gem

• The backend should be able to send thread stacktrace or frame information to the desktop app, which indicates what each thread was doing at that time. This is basically a general information and has nothing to do with profiling, but can be very valuable. I have also been wondering, if it will be possible to send this frame information, down to C method calls. We should def. explore and see if it is possible.

• In the long run, the rbkit gem should at least support 2 modes of profiling a Ruby application. A sampling profiling mode and a full method profiling. Sampling profiling mode will be obviously faster. I think for first cut, we should only implement full method profiling, but our API should be designed in such a way that - which type of CPU profiling user has asked for can be selected easily.

• Considering full method profiling mode for now, backend should gather all data between time t1 and t2 and send it to the client when user takes a CPU snapshot. The time t2 is basically the time user triggered a snapshot and t1 is time user started the CPU profiling session. The backend should ideally keep gathering data past t2 unless user explicitly ends CPU profiling session.

Enhancements to Desktop app for CPU profiling

I think a lot of Desktop UI will become clearer when we have bit of idea about format of data for cpu profiling. But roughly, even tabs etc has to be redesigned a bit to make room for CPU profiling.