Re: Function calls [was: Lua and Neko comparison]

[Glenn Maynard <glenn@...>]

On Thu, Sep 28, 2006 at 03:11:17PM -0500, Rici Lake wrote:
> 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.

I picked an example of a function where the function-call overhead could
be annoying, purely for the sake of giving you an opportunity to explain
what kind of "higher-level interface" you were thinking of.

If you don't like that example, pick any other.  toupper(str, index),
isspace, "convert offset in UTF-8 to a Unicode codepoint" ("iterate
characters in UTF-8"), the whole math library, many others: Bessel
functions, quadratic interpolation, random number generation.  I
think function call overhead could be relevant to any of those; pick
one.  :)

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

strlen() is as fast as sin() in quick tests (on a string of length 90).
It varies by use and architecture, of course, but string operations can
be very fast.

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

Huh?  I've pointed to this very idea (fast function call dispatch)
as a *reason* why adding new operators for performance reasons is
a bad idea.  Adding an operator gives a few people a speed improvement,
at the cost of accumulating complexity in the whole language each time
it's done, and setting a pattern of bloating Lua a little more for
individual use cases.  Faster function call dispatch gives all of
them the speed improvement, in a way that doesn't continue to expand
the language every time someone needs a new one.

-- 
Glenn Maynard