lua-users home
lua-l archive

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



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
interfaces.

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,
support strings.

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 #?