Topics About Contact Resources Quotes

3 Reasons Data-Oriented Design Makes Sense

Data-oriented design, also know as data-oriented programming, allows our data to dictate our solutions as opposed to forcing our data into the solutions that we are already comfortable with.

When we say it like that, it seems kind of obvious.

A programmer's primary function is to transform data, they take some input data and transform it to be something more digestible, useful, or interesting to their users/clients.

So how do we best transform from our input to our desired output, that is the million-dollar question.

Data-oriented design says we are trying to find the best, most efficient way to transform our data not just a passable cookie-cutter way.

1. Data-oriented Design Is Often More to the Point

Programmers do many types of things, there are many "types" of programmers. Most web developers have never written a shader, and setting up a WordPress site has little in common with systems programming.

Across the diverse set of programming domains, there are different concerns, different problems, different common solutions, and different common design patterns.

Data-oriented design is applicable across most programming domains however.

Data-oriented design is not in opposition to object-oriented, functional, or any other programming pattern. Rather data-oriented design instructs us that no programming pattern is the best answer to every problem.

We will often use pieces and parts from different design patterns, but only when they make sense in solving our problem, not just because.
There is no one size fits all.

For example, we can fit most things into some general object-oriented setup that seems safe and familiar, however, are we asking if this is the best representation of our data, in some cases it may be, but we still have to ask.

Sometimes we set up certain structures and design patterns not because they are the best way to solve our particular problem, but because there is a standard way to solve problems that are generally like ours.

So we add unnecessary bloat to our code, we add unnecessary layers to our code, we add unnecessary complexity to our code, and all in the name of abiding by some programming paradigm.

This ought not to be, we should be answering the specific question in front of us - how to transform our input data into our desired output data.

If a certain programming pattern or paradigm can help us, great, but if it is not helping us in reaching our desired output data it should be discarded.

Remember the design patterns are there to help us.
They are not there for us to blindly follow them.

2. Data-oriented Design Often Has Performance Benefits

One of the primary attractions for data-oriented design is the potential performance benefits.

When we are setting up a factory, cookie-cutter website, performance might not be a high priority or it might have already been taken care of by some other programmer further upstream.

But when our application is more heavily orientated to logic or intensive rendering or both, we should have performance as a high priority.

So how can data-oriented design help us?

Primarily by better data layout.

Great. What in the world does that mean?

Let's take an object-oriented example.
We have a projectile object, and in our application, there are many many projectiles at any given time. In our projectile object, we store everything that relates to our projectile.

If you want to do anything with this projectile - no worries - all the information is right there in the object.

Well that seems convenient.

Is there a price for this type of design though?.

There is a price, in our application, we run through many projectiles one after another, the bigger those objects are the fewer will fit in our cache (our fastest memory) what is the result? .

Poorer performance than if we had put some thought into our data layout because our computer has to move more things in and out of the cache.

Ok - what does thinking about your data layout look like?

Let's look at our code and see what things are commonly needed at the same time and package them together, but if they are not commonly needed at the same time let's keep them separate.

Why? Because when we load a collection of things in our cache we want the things to be as small as possible so we can get as many in there at a time as possible.

Seems pretty simple no?

Of course, optimizations can be very difficult in practice, but the ideas underlying them are simple.

3. Does It Make Sense to Answer a Question Before It Is Posed?

How can we know the best way to transform our data before we know what the data is?

The data we are given as input should determine the solution that we employ to transform said data.

Our thought process should not be how can we fit our data into our favorite way to program, our favorite language, or our favorite tool, rather what tools, what languages, what types of data layouts are best for the data we were given.

We can model just about any data into a generic object-oriented template, but that does not mean it is the most appropriate solution to our problem.

We have to reason about our specific problem and determine the most direct and efficient solution.

Sometimes we might have to do things that are a bit more difficult.

That is OK.

Sometimes we might have to think a bit more.

That is OK.

Sometimes we might have to learn something new.

That is OK.

We need to do whatever it takes to get from our input data to our desired data.

If we have to grow a bit on the way, that is OK.

Conclusion

We view data-oriented design like a tailored suit as opposed to an off the rack suit, in many situations the "off the rack" suit will be sufficient, but if you want to or need to go the extra mile data-oriented design can help us to tailor our solution to be cleaner, and more efficient than it would be otherwise.

Resources