Oso Memory Profiler - Overview
Memory profiling for the 21st century.
- C-based SDK for easy integration into any application.
- Supports profiling of Windows, MacOS, iOS/tvOS (Maybe), Android (Native; Clang), and Linux (Clang) applications.
- Includes C++ global new/delete operator implementation to help get you started.
- Low overhead when profiling.
- Write profile data to a file, or stream over TCP direct to the Oso Memory Profiler.
- Define your own memory block types.
- Add custom attributes to your profile events.
- Write your own predicate functions for customised error/warning tracking.
- Insert messages into the profile data to give context to the data.
- Incredibly powerful, intuitive user interface.
- View a map of your application's memory footprint (with fragmentation estimates) - down to individual bytes.
- Filter visible events with ease.
- Gain valuable insights into your application's use of memory.
- Share profile data with your colleagues right from within the Oso Memory Profiler.
There are two primary types of graph:
- Memory Graph
This graph shows you how much memory is being used by your application at any given time.
- Change Graph
The change graph shows how much memory your application has allocated and freed for any given point in time. This type of graph makes it very easy to spot spikes in your application's memory usage patterns.
Each of the graphs breaks down memory usage by block type, to further make it easier to distinguish different parts of your application.
In addition to the two main types of graph, you can also modify the horizontal axis to represent either time or memory events. The former obviously showing you how memory was consumed during the lifetime of your application, while the latter gives you a better navigation space by compressing long periods of inactivity.
The graphs can and should be used as an initial navigation tool into the event streams. The shader area will show you which part of the profile is currently being displayed in the event streams. Or, in the case of the memory map view, which moment in time is being studied.
Threaded event streams
Threaded event streams
Events rising up from the middle of the stream are allocation events, while events falling down from the middle are free events, where the length of the event bar gives an indication of the size of the memory block being allocated or freed. The colour of each bar is defined by the type of memory block being allocated or freed.
Message events occupy the entire vertical space within a stream, and are coloured directly by the application when generating the message event during profiling.
Finally, significant gaps in time where no events occur are marked as bars over the entire vertical space of the view. The length of the gap is shown at the top of the view.
Events will usually have clear backgrounds (I.e., the colour of the stream will be visible behind them), but any events with errors or warnings associated with them will have red or yellow backgrounds respectively.
You can click on any event to view detailed information.
The memory map is split into two halves:
- The top half shows a higher level view of 64KB memory pages. Each page in this section shows you how much memory in any given page is actually
allocated (the height of the coloured block), while the colour gives an indication of how fragmented memory is within that page.
- The bottom half shows individual bytes within the selected page. Allocated blocks are rendered using the colour defined by their type.
You can click on any allocated block to view detailed information.
Grouped memory blocks
- By block type
The Oso Memory Profiler supports two different block types by default:
- Memory blocks
Technically everything is a memory block, but in this instance, these are any block that doesn't have a user defined type.
- Memory buckets
A memory bucket is essentially a single memory block from which actual memory blocks can be allocated by a memory manager that provide pooled memory management.
In addition to these standard types, however, an application can also register its own custom types. Typically you would use these types to distinguish how memory is being used. For example, you might want to be able to see memory which is used for images. Registering an image type through the Oso Memory Profiler's SDK would allow you to do this.
- Memory blocks
- By header
The second level of grouping (essentially each row within the blocks view) is the block header. For standard block types the header is merely the size of the memory block in question, but custom block types are free to specify custom format strings that can use any registered attribute types to create a header string. In the above image type example, a block header might consist of the width and height of the image. In this case, the Oso Memory Profiler would group images of the same size together.
Clicking on any frame in the tree will open a new filtered events view, so you can quickly view and assess any potential problems.
This pane also serves as a legend for the thread streams in the main part of the Oso Memory Profiler window.
Detailed event information
Detailed information is split into four distinct parts:
The header section at the top shows at a glance what was allocated, where it was allocated (which thread at least), and when.
Each event related to a memory block will have at least one callstack - for when the memory block was allocated. As long as the memory was freed later, there will also be a second callstack for that free event.
Messages will have a single callstack for when the message was generated.
Any problems which have been identified will also be listed with as much information as possible to help identify exactly what caused the problem to be identified in the first place.
Finally, all known attributes about an event will also be listed. These will include application defined attributes as well as standard event information presented in attribute form for completeness.
Easily locate problemsThere are several different types of problem that the Oso Memory Profiler can detect automatically. In addition to these you are free to define your own error and warning expressions that the Oso Memory Profiler will evaluate while a profile is loading.
The standard problems that the Oso Memory Profiler will detect are detailed below: