Re: sparse components
Richard Fabian <raspo1 <at> gmail.com>
2010-06-01 16:38:47 GMT
On 1 June 2010 17:19, Mat Noguchi <matthewn <at> bungie.com>
I think that was my quote! (:
Anyways, one reason why you’re probably finding inspiration in
older tech (SQL) is that back then the SQL optimizations were quite hardcore,
dealing with insanely slow external storage and limited memory. (Just like slow
main memory and limited caches.)
Oh, yes, so very yes. This is something I only noticed after I'd been hacking at data oriented development for a while, and it gave me hope that I was on the right track with what I was realising. I've still got a general problem with appreciating joins on tables. I haven't been able to look at them without getting scared of the N*M problem, but think that most of the joins I would have done in the past on database queries are now sequences of selections with decision tables built from previous selections. At least that way I get to sleep at night ;)
I'm wondering if the old convoluted queries we had to do for uni' were a result of business logic, and need to test our skills. I'm hoping that I'll find out one way or the other when I get around to the more complex combinations of data (I'm guess that will be when I get to the monster AI in the roguelike).
Other potentially hazardous queries, such as selecting ranges of values, struck me as quite hard to make fast. That was until I had a brain bulb go off. I've now come to the conclusion that they are eminently simple to optimise with techniques varying on a case by case basis but usually being some combination of indexing and cached sets. I've got a whole section of my work devoted just to optimisations on selecting values from tables.
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
Sweng-Gamedev <at> lists.midnightryder.com