Results in minutes
|Guessing||Developers usually have a instinct of where the performance bottlenecks are, and focus on those, without proving via characterization.||Easily mislead by pre-conceptions, and may not take into account context switches, cache misses, more threads than cores, etc.|
|printf()||Print elapsed times, or key execution points.||Obtrusive to real-time due to system context switches. Difficult to track thousands or millions of events.|
|Function Profilers||Provides average times for running functions. For example: GNU's gprof.||Does not per-event details making it very difficult to verify determinism or see little details in a pool of large functional averages.|
|OS Analyzers||A lot like EventView but mostly shows OS details: process/thread context switches, mutex/semaphore grabs, file IO, interrupts, etc.||Overwhelming with events that may be difficult to relate to the application.|
Developer knows best
Developer defines session properties
Developer defines event properties
Developer decides when to flush stored events to a disk file
(Bring Your Own Clock)
Use the default OS clock, or provide your own by passing initClock(), finalizeClock(), and getClock() functions when defining a session.
When events are recorded, only a minimal number of values are stored to a contiguous memory buffer keeping overhead very low. The only time consuming call is to get the current time – the developer has control over what clock is used, so can choose one with minimal performance impact.
The only time a significant performance hit is incurred is when the existing events in the event buffer are flushed to disk – the developer has control over when this will occur for minimal application impact.
Sessions, threads & interrupt handlers
The developer creates a session in which events are recorded
Recording events within threads
A single event session can be used across multiple threads.
Recording events in interrupt handlers
Interrupt handlers, dedicate a session to just the handler.
• View sessions from multipleprocessors simultaneously.
• Align multiple sessions from multi-processor apps, or just comparing two different sessions from one app.
• Sort events by name, thread, or ID.
• Group events by file, thread, oruser defined folders.
• Dive down to the nano-secondlevel.
• See implicit events such as context switches or cache misses.
• Filter out events as needed.
Place the mouse over any event to see great detail.
Use histograms to visualize and characterize determinism.
- AXIS - Taking the Sting out of Multiprocessor DSP Application Development
- AXIS Software Development Tools
- Software Challenges When Developing Applications for Multiprocessor Embedded Systems
- Strategies for Open Architecture COTS Operating Systems
- AXIS Takyon: a much-needed solution to communication in embedded HPC applications
Request a Quote
Contact an Expert