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