[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Another attempt at SpeedingUpStrings
- From: "alex.mania@..." <alex.mania@...>
- Date: Tue, 18 Dec 2007 15:29:06 +0900
On Mon Dec 17 23:56 , Rici Lake <firstname.lastname@example.org> sent:
> Do be aware that stack relocation during execution of a CFunction
> is fairly rare in practice, with the consequence that bugs may not
> be visible during normal testing.
I just realised that could extend to any operation that calls a GC step - very,
very rarely the GC may shrink the stack. I think that's the very definition of
On Tue Dec 18 5:03 , Javier Guerra <email@example.com> sent:
>i really want to agree; and of course it warrants a benchmark or two.
>but still, using string constants in Lua is (almost?) as light as
>using integers, and i'd like to have this from C; ideally using enums
>that get translated to already-interned lua strings.
>unfortunately, i don't believe there's a neat solution.
Although it'd need to be rewritten for future versions of lua, you could write
yourself two very simple functions. One pushes a string, marks it as fixed (so
that it is never GC collected), and returns a pointer to the TString object.
Another pushes the TString object. Then you could just save them all in to global
variables at runtime, and using them would be no slower then pushing a light
userdata. But again, that's unportable between versions of lua.
On Tue Dec 18 1:29 , Mark Hamburg <firstname.lastname@example.org> sent:
>I've been thinking that it might be useful to build a suballocator for Lua's
>memory allocator that would hold onto freed blocks until the next round
>through the garbage collector. Has anyone played with anything like this.
>The one crude part is that to get it going without changing the Lua VM, one
>would basically need to have a userdata object with a __gc proc that would
>essentially say "flush the free lists" but this isn't really quite the
>message I'm looking for and probably means that memory retention on the free
>lists is even higher than one might want.
If you want to build a better malloc, there's no need to make it Lua specific.
Although be aware you would be hard pressed to beat the malloc provided by a lot
of compilers. Rarely are they just a wrapper around API calls, in many cases
they're quite optimized.
For reference, I'm using FastMM4
(Written entirely in asm, support for all instruction sets and utilizes runtime
patching to call the most optimized functions for the architecture). Read the
technical details for more info if still interested.