Multi-core and Embedded Software: Optimize Performance by Resolving Resource Contention
Deployment on multi-core CPUs should make software faster. But processes running in parallel often contend for system software resources, actually reducing overall performance. Achieving multi-core’s promised linear performance gains hinges on resolving this issue. This Webinar looks at two such conflicts — contention in updating a shared data store, and threads vying for access to the C/C++ memory manager — in-depth, and addresses them with techniques that can provide the basis to solve other multi-core resource conflicts.
Webinars for Professional Developers
Watch to on-demand Webinars, hosted by experts, about proven database management system practices. Watch “Eliminating Database Corruption“. Or, “Embedded Databases: Make or Break Technology Choices for High Performance Applications” and others.
Review our list of Webinars
Embedded Databases: Building In Always On High Availability
This Web seminar highlights the issue of operational continuity: how can a database system survive the failure of the software or hardware environment in which it operates? How can it deliver high performance as well as fault-tolerance? Led by McObject CEO Steve Graves, this Webinar presents development solutions that address the “always on” needs of fault-tolerant systems, while taming these applications’ growing data complexity.
Eliminating Database Corruption
Applications that manage data (that is to say, nearly all applications) are at risk for data corruption, and its resulting garbage output, crashes and drain on firms’ technical resources. This Webinar explains why corruption occurs and provides strategies to prevent it, focusing on hidden dangers – like storage device settings that can undermine data consistency – as well as more recognizable risks, such as passing wrongly typed data to a database run-time.
Embedded Databases: Make or Break Technology Choices for High Performance Applications
The advantages of proven, third-party database software for embedded systems are great. But the sheer volume of database technology options is huge, and choices can significantly affect results. This Webinar provides a roadmap, looking at critical distinctions such as client/server vs. in-process architecture, SQL vs. navigational APIs, and different approaches to fault-tolerance.
Using Data Indexes to Boost Performance and Minimize Footprint in Embedded Software
The right index can boost lookup speed logarithmically, and reduce RAM and CPU demands. While the B-Tree is the best known index, many others can be more efficient in specific circumstances, such as geospatial/mapping and telecom/networking applications. This Webinar examines less well-known indexes including T-Tree, Hash table, R-Tree, Patricia trie and others. It emphasizes index implementation methods that avoid data duplication, to minimize an memory footprint.
Articles for Professional Developers
Review a list of articles
Code Size vs. Memory Footprint And Why They Matter
The terms “code size” and “footprint” are often used interchangeably. But they are not the same—code size is a subset of footprint. In this article, McObject CEO Steve Graves explains the difference and relevance. He then describes some techniques to minimize footprint.
Data Indexes Boost Embedded Software’s Performance and Efficiency. This article in Military Embedded Systems explains the benefits of specialized database indexes such as R-Trees for mapping and navigation, and Patricia Tries for communications systems.
Comparing Optimistic and Pessimistic Concurrency
Usually (with rare exception), a database is a shared resource, meaning that it is used concurrently by two or more tasks. This leads us to the topic of concurrency control; i.e. how do we coordinate a tasks’ access to the database? This is part-and-parcel of providing a database management system that adheres to the ACID properties.
Does Dr. Who Use An Embedded Database? This technical article in EPN explains how a type-safe API is used to bolster stability in an aerospace system.
Change Data Capture in Embedded Databases
Change Data Capture (CDC) is broadly defined as tracking changes in a database. The purposes of tracking changes are many and varied. CDC in embedded database systems can be implemented in several different ways that are sometimes invisible to applications, and ways that applications can exploit for data sharing, responding to events, and incremental back up.
White Papers for Professional Developers
We have been testing, improving on, and retesting our software from the beginning in 2001 in order to provide our clients with the best possible data management solutions. Read “Database Persistence, Without The Performance Penalty” and more.
Review our research
White paper: Exploring Code Size and Footprint
The terms ‘code size’ and ‘footprint’ are often used interchangeably. But they are not the same; code size is a subset of footprint. This paper will explain the differentiation and relevance, then proceed to describe some of the techniques employed within eXtremeDB to minimize footprint.
A distributed database system is one in which the data belonging to a single logical database is distributed to two or more physical databases. Beyond that simple definition, there are a confusing number of possibilities for when, how, and why the data is distributed. Some are applicable to edge and/or fog computing, some others are applicable to fog and/or cloud computing, and some are applicable across the entire spectrum of edge, fog and cloud computing.
White paper: Will the Real IMDS Please Stand Up?
In-memory database systems (IMDSs) have changed the software landscape, enabling “smarter” real-time applications and sparking mergers and acquisitions involving the largest technology companies. But IMDSs’ popularity has sparked a flurry of products falsely claiming to be in-memory database systems. Understanding the distinction is critical to determining the performance, cost and ultimately the success or failure of a solution. This white paper examines specific products, seeking to answer the question, “is it really an in-memory database system?”