I think I'm even more confused now than I was before. People, and even you, are saying that DOD is more efficient, but at the same time you're saying that it's not? It is but it isn't? :(
Efficiency in code is a strange thing. Typically the inefficiencies are not what you expect. Generally the first time a program is analyzed for performance all kinds of weird stuff shows up. You might discover billions of calls to string comparison, or billions of iterations through some loop deep-down in the system.
It is rare for performance problems to be exactly you expect them to be, unless you've been doing performance analysis for years, in which case occasionally you can guess right.
Data oriented design is more efficient because you wrote and tested for that specific thing. You spent time and effort ensuring that the system will efficiently travel across the data. Perhaps you have a half million particles and you build a particle system, your data oriented design will ensure that the CPU streams quickly and efficiently over those half million particles, taking advantage of cache effects and whatever prefetch commands are available on the system.
It takes a great deal of testing to ensure something that claims to be data oriented really is.
In my studies, it was said that computationally speaking OOP has a larger footprint because data is spread throughout memory rather than being stored in one place. It would be more resource intensive to perform searches on that data than a DOD approach would lend itself to. Was that wrong?
Yes, that is a poor generalization.
Object oriented programming is based around clusters of objects and operations. There is typically no significant difference in memory footprint. Data can potentially be scattered across memory if that is how the programmer wrote it. This is not a problem by itself if the operations are naturally scattered. However, if operations are sequential, and also if memory cannot be linearly traversed, then your code might not to take advantage of certain benefits from locality of data. Note there are several conditions involved there.
Data oriented development means actively seeking out those conditions and intentionally taking action to ensure when you perform sequential operations the memory is traversed in a hardware-friendly way.
Programmers who follow object oriented rules can completely violate the rules of data oriented development. They can also closely follow the rules of data oriented development. The two are unrelated.
You mention that DOD is an approach that prefers continuous strands of data, which would be easier and quicker to handle than v-table searches. I don't understand.
It has nothing to do with vtables.
Going back to a particle system example:
A naive programmer might make a particle object. They'll give the particle a position, mass, velocity, and several other variables. Then they will create an array of 500,000 particle objects. When they run the code, they will iterate over each object, calling 500,000 functions. Each function will update the object, then return. They'll provide many different functions to manipulate the particles, and whenever they work with the system, call each function 500,000 times.
A more savvy programmer might make a class of particles. They will create an array of positions, an array of masses, an array of velocities, and a way to set the number of particles, taking care to ensure the processing works on an interval that steps one cpu cache line at a time. Generally working within the cache you only pay the cost for the initial load, so if you can fit 4 in the cache at once you pay for one, the other three are effectively free. The programmer can then set the number to 500,000 particles. Then they will make a single function call which will traverse all 500,000 particles all at once. They'll provide exactly the same functionality to manipulate the particles as above, but each will be completed with a single call that processes all particles, rather than an enormous number of calls that process each particle.
An even more savvy programmer might take advantage of SIMD calls on the system to process 4, 8, or more particles at a time rather than processing them individually in a tight loop. Then instead of just having four in the cache and paying for a single cache load, they'll also only pay for a single operation rather than four, giving even faster results.
All three of them have the same effect of calling 500,000 particles. Two of them just took better advantage of their hardware's capabilities.
Also note that this type of design only works in limited situations. There needs to be LOTS of things that can be accessed sequentially. Lots of particles being shifted. Lots of pixels in an image filter. If there are a small number of items, perhaps only a few hundred or a few thousand, the benefit is probably so small to not be worth it. Also if the items cannot be arranged sequentially the design change does not work.
I want to develop for mobile, where performance and resource usage appear to be quite important.
Your concern is admirable but misplaced. This is something you should not worry about in about 97% of the time. In the rare roughly 3% of the time it should be very obvious that you need to do something about it, you will not miss it by accident.
The rules for optimization are:
1. Don't worry about it.
2. Advanced: Don't worry about it yet.
3. (Experts Only): Don't worry about it until after you've carefully measured, then only worry about those specific pieces indicated by measurement.