I'm also really interested in the topic of indexing a CES game engine. At one point I was trying to build a game, and mine was designed with components being maps of entity-id -> value. I found that it worked really well to quickly do things like running a function for all entities that have a hunger component (for example), but I soon found myself wanting to filter entities based on some arbitrary criteria, like "run this function for all coniferous trees with age greater than X". If the environment has tens of thousands of trees, it would be nicer to have an index on the age, along with an index on the variety of trees, so that it doesn't have to iterate over more entities than necessary.
Every time I go to the hammock (so to speak) to think over how to design such a system, I realize that I'm just re-inventing the database, so I come away feeling like somewhere, somehow there must already exist an in-memory database that will suit the problem, but I haven't determined what it is yet. On Thursday, May 12, 2016 at 11:51:31 PM UTC-5, James Reeves wrote: > > If we want improve lookup performance in a SQL database, we place an index > on a column, or a group of columns. The same idea can be applied to a data > structure we keep in memory. > > So if you know that you want to lookup entities by position and velocity, > you could have an indexing function like: > > (fn [index entity] > (when (and (:position entity) (:velocity entity)) > (assoc-in index [:mobile (:id entity)] entity))) > > And then you just need a way to run that index each time an entity is > added to your in-memory database. Naturally you'd also need a "unindex" > function as well. > > I've written a game library called Ittyon that works along these lines. > > - James > > > On 13 May 2016 at 00:31, JvJ <kfjwh...@gmail.com <javascript:>> wrote: > >> I'm intrigued, but I don't know exactly what you mean. >> >> On Thursday, 12 May 2016 16:25:05 UTC-7, James Reeves wrote: >>> >>> Have you considered defining specific indexes? For instance, if you know >>> ahead of time that you want to search for entities that have both position >>> and velocity, you could define an index that keys both of those values. >>> >>> - James >>> >>> >>> >>> On 12 May 2016 at 23:50, JvJ <kfjwh...@gmail.com> wrote: >>> >>>> Maybe this is a little off-topic, but on the general topic of >>>> performance, other than just numerical performance, what's the best way to >>>> get information/advice on how to improve it. >>>> >>>> I went about doing these tests (and other tests) because I'm trying to >>>> create a game scripting framework in clojure, which I want to build around >>>> an entity-component-system architecture. Entities are maps of >>>> components, and system functions are defined to sort of "pattern match" >>>> against >>>> entities to see if they have the required components. (i.e. an >>>> update-position function would add velocity to position, so it only >>>> applies >>>> to entities >>>> with both a position and a velocity component). >>>> >>>> The first step in this process is to find a way to store these so that >>>> it would be as fast as possible to iterate over "all entities with this >>>> set >>>> of components", >>>> while avoiding things like filter operations. >>>> >>>> I started off by making cross-map <https://github.com/JvJ/cross-map>, >>>> which cross-indexes any entries with keys of the form [r c], where r is a >>>> row and c is a column, and allows O(1) access >>>> of entire rows and columns. >>>> >>>> Still, though, the performance tests >>>> <https://github.com/JvJ/cross-map/blob/master/test/cross_map/perf.cljc> >>>> aren't what I expected they would be, and I'm wondering how to go about >>>> dealing with that. >>>> >>>> Again, this isn't strictly about numerical performance, but it's why >>>> I'm doing these kinds of tests in the first place. >>>> >>>> Thanks. >>>> >>>> On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote: >>>>> >>>>> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto <brob...@gmail.com> >>>>> wrote: >>>>> > Fair enough, but in this case types wouldn't really have helped: the >>>>> author did use `Double` type hints, mistakenly assuming that would make >>>>> its >>>>> code use primitive types, which it does not since `Double` is boxed and >>>>> not >>>>> primitive. >>>>> > Clojure already has compile time warnings about boxed math that >>>>> would've helped in this case if turned on, without any need for types: >>>>> try >>>>> compiling OP's code after running `(set! *unchecked-math* >>>>> :warn-on-boxed)` >>>>> >>>>> Thanks for the details re: double. Apologies for being annoyed/ing. >>>>> >>>>> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We >>>>> can relive the ignominious history of "$!" in Haskell. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@googlegroups.com >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+u...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to clojure+u...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
