Re: Unpooled strings?

[Chip Salzenberg <chip@...>]

On Tue, Apr 29, 2008 at 03:42:59PM +0800, Alex Davies wrote:
> Jerome is right though. Any function in the string library except for  
> string.len is likely to [greatly] exceed the time taken to intern the  
> string, making the optimization moot.

Thanks (to Alex and Jerome both) for the perspective.  Further system
analysis of my application suggests that the max length will be a little
over 100K with an average that's much smaller.  Perhaps the wisest path
forward is to prototype with interned strings, and then look for the
hotspots.  Premature optimization is, after all, the root of all evil.

> Also there's quite a bit of complexitity there and features lost. Eg 
> without modifying the core, you could never get equality to work 
> correctly between the strings (which, due to not being interned, would 
> always require a full memory compare anyway), or table hashing for that 
> matter. Mind you, this may not be an issue for very-likely-to-be-unique 
> multi hundred k strings though.

Indeed, I could do without a working equality operator on these strings.
Also, I wouldn't mind if derived strings (e.g. extracted substrings) were
interned, which means "this bit equal to that bit" would still work.

> One thing that puzzles me though, is if they're constant... why not just  
> push them at the start of the program?

I'm adding Lua to an existing application which processes a data stream.
The data come in, the data go out, and they are never seen again.

> http://lua-users.org/wiki/SpeedingUpStrings

Thanks again.
-- 
Chip Salzenberg <chip@pobox.com>