Re: SV: Deep Copy prototype

[Luiz Henrique de Figueiredo <lhf@...>]

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

I hope not :-) Anyway, Lua stores single copies of strings ever since 2.4.

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

Like everything else in Lua, strings are kept in a hash table. They are
only hashed once, when they cross the C/Lua boundary (eg, in lua_pushstring
or internally when the VM concatenates strings). Once in Lua, no more string
hashing is needed. Like I said, string comparison becomes pointer comparison
and strings become as fast as any other value (all comparisons are in effect
pointer comparisons, except for numbers, booleans, and nil).

The memory overhead for strings is simply its hash value, which is an int.
The time overhead is deciding whether a string is already in the string table
and, if not, to add it. This is as hash table and thus should be fast, as fast
as (actually faster than) table lookup, on which everything in Lua is based.
--lhf