lua-users home
lua-l archive

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


On Thu, May 08, 2003 at 08:17:22AM -0300, Luiz Henrique de Figueiredo wrote:
> >One thing which worries me slightly is potential speed issues.
> Have you seen any speed problems in Lua?

Not currently, but I am embarking on a project which does a massive
amount of string manipulation, and I was worried that if this could
potentially be an issue, I may switch to a different language for the
work.

> >Then the storage for c and d are the same memory?
> Yes. That's how strings work in Lua. The benefit is speed: string
> comparison is simply a pointer comparison.

I see

> >If so, then I hope there's a way to turn this off because it seems to me
> >to be a hideous performance issue.
> No way to turn this off. Like I said, it's likely to help your
> application.  It's based in hashing.  Lua even goes out of its way to
> avoid reading the whole string to hash it if the string is very long.

I can certainly appreciate that in the simple-case, this makes sense. I
am merely trying to work out if there is any pathalogically bad case for
this to work with which I might hit.

E.g.

If my program has, for argument's sake, two hundred thousand individual
strings, all different. And I read a new string in from an input file;
then how much work is done to determine whether lua can save the, let us
say 64 bytes of, storage for the string? Also, how much memory is Lua
using in order to make those checks efficient?

I'm not saying it's a bad thing that Lua is memory efficient; I am
merely trying to determine if this is something which will eat CPU in my
case.

D.

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Love is in the offing.  Be affectionate to one who adores you.