Performance: Memory and CPU

Overview

CoreDX DDS provides a perfect balance of performance and resource conservation that is well-suited to projects that rely on distributed software to deliver high-performance systems. And you don’t need enterprise class hardware to host CoreDX DDS. Our software can be employed on the widest range of hardware platforms - from deeply embedded systems to consumer-grade computers to enterprise servers.

Our focus on optimizing processor, network, and memory resources makes CoreDX DDS the smallest footprint DDS implementation available. The memory utilization metrics show that CoreDX DDS achieves ultimate performance without the memory bloat exhibited by other messaging infrastructures.

Memory Footprint

CoreDX DDS exhibits stable memory utilization at run-time. This critical aspect of middleware components is often overlooked when examining performance. A middleware that consumes extreme amounts of memory during execution is not suitable for deterministic or resource constrained systems: these bloated products must be hosted on enterprise class hardware, and this leads to increased costs.

Your computing resources (run-time and static memory, CPU processing cycles, disk space), whether they are limited or abundant, should be available to your applications for use, not devoted to your middleware. CoreDX DDS is optimized at every step of the development process to use minimal amounts of memory.

An example CoreDX DDS application with:

• 1 Domain Participant,
• 6 Topics,
• 6 DataWriters, and
• 4 DataReaders

will require < 100 KB of heap memory.

Our 'C' shapes demonstration, TOC Shapes, used during all interoperability testing and demonstrations, uses < 300 KB of heap memory (this measurement includes the graphics libraries). This particular memory utilization number was obtained from a running TOC Shapes demonstration with 1 Writer on the Square Topic. If we delve into the architecture of the TOC Shapes demo (source code for the TOC Shapes Demo is freely available here), we find that this running demonstration had:

• 1 DomainParticipant,
• 3 Topics,
• 1 DataWriter,
• 0 DataReaders

The following table details the amount of memory required for each CoreDX DDS Entity created. This information can be used to roughly estimate the amount of memory CoreDX DDS will consume in your application.

* DomainParticipant size includes all built-in Topics, DataWriters, and DataReaders

The following graphs show that CoreDX DDS can maintain a small and consistent memory footprint during execution of latency or throughput heavy applications. The memory graph includes all memory assigned to the program, including: text (code), static and local variables, stack memory, and heap allocated memory.

CPU Utilization

The CPU Utilization graph shows a long running throughput test, transmitting 1024 byte messages, with a total throughput of over 700 Megabits/sec. The CPU utilization of a single core doesn’t exceed 30%. On a machine with 4 cores, this equates to less than 10% of the total available CPU resource.

From this analysis, it is apparent that CoreDX DDS with its small memory footprint and high-performance provides a well-balanced communications middleware that supports a wide range of platform deployments.