Re: Data oriented programming

I'm with Tony on this one: Too many times "just write it and we'll optimise
it later" has come to bite.

So many times it's been "just add a system to do this", and then three years
later, we're not using it the way it was originally intended due to
performance issues. For example, scripting languages that get too slow, get
compiled to code, then get optimised further by doing trickery, then some
random guy walks up and says, "so why not do this stuff in code anyway" and
gets bashed for pointing out the painful but obvious.

Don't trap yourself in thinking that something that seems easy to use, can
ever be made fast enough to USE. If you wait until your performance slot
(say one year before release), then you're in for an almighty headache as
you have to do awful things like change the way in which you even approach
certain problems. Take some visibility algorithms for example, how many
different ones are there? Portals, PVS, octree, BSP, blah blah blah.....
don't think they're all there because someone thought "ooh, i'lll try doing
it this way." No, they did it because in different circumstances, different
algorithms do better than others, either due to layout of your levels, or
layout of the code using it, or simply the access patterns into the
structure. For anyone who's actually done a complete conversion of visibilty
system from one to another, changing data structures and access techniques
throughout a codebase: I feel your pain.

There are many different ways to lay out your data, some are performant,
some are easy to manipulate... Not many are both.

Apply natural selection: If you don't care about performance from day 1,
then manipulability wins over performance. Thus ends the tale.


On 6 October 2010 05:12, Tony Albrecht <[email protected]> wrote:

> So you are recommending that you shouldn't think about the performance
> impact of your code before you write it?
>
> I think you should. If you are working on code which is likely to have a
> performance impact on a system, then you should think carefully about the
> layout of data and code. Smart decisions at the start will save you a lot of
> time in the long run. I've worked on systems that are incredibly difficult
> to optimise due to uniformly slow code where a week spent fiddling around
> during the design of the system would have saved months down the track.
>
> -Tony
>
>
> On 6 October 2010 14:18, Gregory Junker <[email protected]> wrote:
>
>> >
>> > I didn't mean to suggest that you shouldn't test performance during
>> > testing, just that it shouldn't be your "first line of defense".
>> > Obviously you can't fix problems before you notice them, but a lot of
>> > these problems are entirely avoidable if you think things through early
>> > enough.
>>
>> Which can easily lead to "analysis paralysis"...
>>
>> Greg
>>
>> _______________________________________________
>> Sweng-Gamedev mailing list
>> [email protected]
>>
>> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>>
>
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>


-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com