lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


(fyi, that link leads to limbo..)

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