I don't really get the reason for having all that stuff on the c side..
Why not just do the prio-queue in lua?
Don't remember where it is right now, but Rici released some priority
queue code in lua a while ago...
Also, as a general rule (especially since you seem to favour rapid
development/testing/etc as opposed to raw speed), don't preemptively try
to optimize like this until you're certain of what is actually slow.. I
would do the whole thing in lua, then pinpoint any reason that would
impact performance,
and move that over to the C side.. I guess that's common practice
though, but a lot of people (especially in the gaming industry) seem to
take it too far too soon,
and for little or no reason.
I'm just rambilng now I guess :)
Wesley Smith wrote:
> Did you see that the LOOP library already has Priority Queues?
> http://loop.luaforge.net/docs_classlib.html#collection
>
> wes
>
> On 7/25/07, Geoff Leyland <geoff_leyland@fastmail.fm> wrote:
>> Thanks Jerome,
>>
>> On 25/07/2007, at 5:07 PM, Jérôme Vuarand wrote:
>>
>> > 2007/7/24, Geoff Leyland <geoff_leyland@fastmail.fm>:
>> >>
>> >> One way I can imagine doing this at the moment is to create a table
>> >> in the registry and store the lua functions at indexes in that table,
>> >> and then store those indexes in the priority_queue. That way, Lua is
>> >> aware that I'm interested in those objects, and I have a way of
>> >> keeping hold of them. Popping to top off the priority queue will
>> >> also mean removing an element from the table, which I imagine will be
>> >> a little inefficient. Possibly more than I'd like, but I'll have to
>> >> see.
>> >
>> > I think this is the right solution.
>>
>> And I think certainly the one I try first, though I might just start
>> by doing it all in Lua to get an idea of what it looks like (I'm
>> particularly excited about using coroutines!)
>>
>> > If your Lua objects are userdata instead of functions or tables, you
>> > can store them directly in the registry, with the userdata itself as
>> > value, and a lightuserdata pointing to the full userdata as the key.
>> > You can then store that lightuserdata in your priority_queue. This
>> > removes the need for an intermediate table, and it may be easier to
>> > manage than integers.
>> >
>> > This means that you will use the hashmap part of the table instead of
>> > the array part, but since your data structure is a queue it may end up
>> > being a sparse array and anyway use the hashmap of the table.
>> >
>> > That's just ideas to widen your perspectives, do not take it as an
>> > expert's advice ;-)
>>
>> That's a good idea, though I think they probably won't be userdata,
>> though at the moment, I'm just trying to get my head around how it
>> might be done, so you never know.
>>
>> Cheers,
>> Geoff
>>
>>
>
