lua-users home
lua-l archive

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


On Wed, Jul 17, 2013 at 11:31 AM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
> On 7/17/2013 8:25 AM, Steve Litt wrote:
>> So true Tim. And besides that, if you're not doing a random number
>> generator or a hugely graphics heavy program, is runtime speed
>> really that important?
>
> I do games. I have to do ALL of my upkeep, graphics set-up, AI calculations,
> etc., in 16.66ms or less, or it's going to skip a frame.
>
> Yes, speed is still important. ;P
>
> The rest of your points are good, of course, which is why I'm using LuaJIT
> instead of writing most of the code in C++.
>
> The only way things would be better for me (and games in general) is if
> LuaJIT had an optional reference-counted garbage collector. It seems that
> Lua CAN be modified to use one (see LuaPlus [1]), and the slight decrease in
> amortized performance would be more than offset (for needs of games) by the
> decreased memory required compared to mark-and-sweep and the increase in
> predictability of execution times.
>
> Tim
>
> [1] http://luaplus.org/#What-is-LuaPlus -- tl;dr: "An optional high
> performance reference counted garbage collector."

Perhaps something optional that is along the lines of Apple's ARC:

You retain/release what you need, unless you know it's
retained/released for you. Mechanisms for reference counting without a
garbage collection process. Or perhaps another way to look at it is:
manual allocation/deallocation augmented by garbage collection.

I'm not really advocating for this. I just observe that memory
management is hard and GC is an attempt to make it easy. Things like
ARC feels like an attempt to make it simple.

-- Andrew