[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Function calls [was: Lua and Neko comparison]
- From: Rici Lake <lua@...>
- Date: Thu, 28 Sep 2006 15:11:17 -0500
On 28-Sep-06, at 2:43 PM, Glenn Maynard wrote:
On Thu, Sep 28, 2006 at 02:07:06PM -0500, Rici Lake wrote:
But there is a way to speed up Lua->C function calls:
Interesting ideas. But I think the best way of speeding up the Lua->C
interface is to call it less often; i.e. design higher-level
I want (hypothetically) to implement an inner-loop character count
function for UTF-8 (like strlen, but returns the number of whole
characters). It's inner-loop, so I can't have all that horrible
function call overhead. Can you suggest the higher-level interface
that you have in mind that would solve this? (Without hardcoding
anything specific to my narrow purpose into the Lua core, of course.)
I wrote one of those and I don't find that the horrible function call
overhead is much of a problem. If you want it, I'll post it somewhere.
I also wrote it in pure Lua, which is somewhat slower but still
acceptable for most practical applications.
But I hardly ever use it. What I usually want to know about UTF-8
strings is not how many UTF-8 codes there happen to be, but rather how
big the rendered string would be. There are also a number of useful
regex-like interfaces which can be applied to UTF-8 strings, but none
of them require counting codes.
Now, I do often prototype such programs in Lua, but the intent is
generally to write them in C, as higher-level interfaces (which don't
require modifying the Lua core at all.)
The optimizations you mention seem to apply to the math library only
(nowhere else would prototypes which only involve lua_Numbers be
common), but I can see that speeding up the math library would be a
He only gave examples using lua_Numbers; it would also, presumably,
Sure. However, except for very small strings, the cost of a function
call is hardly noticeable.
Certainly in the case of the math library, the cost of a function call
is noticeable in relation to the cost of computing a sine or cosine.
By the way, am I missing something, or are you a different Glenn
Maynard from the one who said that efficiency wasn't a good reason to
introduce new operators like % and #?