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 <kfjwhee...@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 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.
