Data Oriented Design on maladroit.dev

Component Based Objects

Mon, 01 Jan 0001 00:00:00 +0000

Thinking using components instead of inheritance can prevent needlessly linking ideas that are unrelated to one another. Objects built this way can be processed by component type, rather than object instance making it easier to profile the application. Using components typically can make extending functionality easier too since they often don’t need to modify other existing components. They either extend it or provide alternatives.

Compound Objects

A compound object is a base entity instance that has a list of components. The core object merely holds the components and they communicate to each other through it. The entity usually will update by iterating over root instances rather than systems. This is a great start, but is not a fully component based approach. This way the entity is more readable, reusable, and robust allowing it to support a larger system and be reusable between projects.

Existential Processing

Mon, 01 Jan 0001 00:00:00 +0000

Existential processing attempts to provide a way to remove unnecessary querying about whether or not to process data. For example, in most software it is common to check for null and the verify objects are valid before processing. This entire line of conditional checks can be removed if data could be trusted to be in a valid state before being processed.

Complexity

Cyclomatic complexity is a numeric representation of the complexity of programs, specifically concerning flow control. In short, it is:

Helping the Compiler

Mon, 01 Jan 0001 00:00:00 +0000

While compilers are good at optimizing code, they are not magic wands. It is the engineer’s job to write code that the compiler can reason with and better apply it’s optimizations.

“You don’t have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy.”

- Jackie Stewart

Reducing order dependence

Compilers try doing work ahead of time to increase performance. If the compiler cannot discern that the order of operations is unimportant, then it cannot do work ahead of time. When translating code to an intermediate form, some compilers will use Static Single Assignment (SSA) form. SSA assumes that a variable is never modified after initialization and instead new variables are created for any mutations. This is useful because it allows the compiler to work ahead of time, this is especially true with branches.

Hierarchical Level of Detail & Implicit State

Mon, 01 Jan 0001 00:00:00 +0000

Hierarchical level of detail (HLOD) is a technique where an entity gains or loses detail depending on how relevant it currently is to the user or system. This can even be as extreme as having the entity no longer exist. Since entities can be implicit based on their components and attributes, we can optimize their performance by only loading those components that are relevant.

For example, if 100,000 objects are being observed from a great distance away, it is more efficient to render those objects at a lower resolution since finer details would be impossible to perceive at that distance. The level of detail heuristic can be fine tuned so that the most relevant objects are always at the highest level of detail, while other objects may be reduced to a lower level.

Optimizations

Mon, 01 Jan 0001 00:00:00 +0000

Optimizations cannot be done blindly, you need to know what is causing the code to run slowly. In most cases, data movement tends to be the most expensive operation while running algorithms or functions on data is less expensive. If you begin development by organizing your data into arrays, you open yourself up to many opportunities for optimization. By having such an agnostic data layout, any improvements made can be applied in many locations with little concern for incompatibility.

Relational Data Design

Mon, 01 Jan 0001 00:00:00 +0000

Representing complex data in a computational framework

Data layout and structure is a constant trade-off between performance, readability, maintenance, future-proofing, extendability, and reuse. While more complex tables can achieve higher performance and readability, the cost becomes future proofing, maintainability, and often scalability.

Moving towards a document store type of data storage is incredibly beneficial for their simplicity and flexibility. They are more akin to file systems where documents are accessed by name and have few limitations on how they are structured. This is very good for horizontal scalability since it is easy to add more hardware when data does not need to be consistent across multiple tables/machines.

Searching

Mon, 01 Jan 0001 00:00:00 +0000

The greatest performance gain for searching is not having to search. If the search is unnecessary then it should be avoided. Search helpers like binary trees, hash tables, or keeping data sorted can also aid in finding rows in tables.

Indexes

The concept of an index has been around for a long time in the RDMS world. In the SQL world, learning whether a record exists would involve building a query. This query could start out simple, but overtime could become more complex depending on what data is needed. Even more complex is a query that can hook into the insertion, update, or delete operations for a table to that it could update it’s results without needing to re-run the full query.

Sorting

Mon, 01 Jan 0001 00:00:00 +0000

Sorting is important, however it is not always necessary and can cause more performance problems than it’s worth. There are algorithms that may seem like they require sorted data, but ultimately don’t. On the other hand, some algorithms can appear to not need sorted data when in reality they do.

Be aware of how accurately the data needs to be sorted since unstable sorts are often quicker. For analog ranges, a quick sort or merge sort are slow, but will guarantee accurate sorting. For a discrete range with a large number of elements, a radix sort is the best fit. If the range of values is known at compile time, then a counting sort is a very fast two-pass sort.