[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Function calls [was: Lua and Neko comparison]
- From: Glenn Maynard <glenn@...>
- Date: Thu, 28 Sep 2006 17:16:44 -0400
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
> 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.