It sounds like DataScript may be just what you need: https://github.com/tonsky/datascript Alan
On Fri, May 13, 2016 at 11:50 AM, Michael Willis <willismich...@gmail.com> wrote: > 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> 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. > -- 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.
