Re: too many items in a constructor

[Dimitris Papavasiliou <jimmyp@...>]

On Thursday 30 September 2004 03:27, Bilyk, Alex wrote:
> Well, this depends on how you handle it. A table in Lua takes about 50
> bytes. So, the format above adds about 50+ bytes per pixel, let alone that
> every pixel is represented as double (by default. -- 32 bytes) == 82+
> bytes. On the other hand the RGBA values usually have a range from 0 to
> 256, so that a pixel can be represented via 12 byte string+length == 16+
> bytes. Now, in many images some pixels have the same values and if so, in
> Lua, they would be represented via same string object firther reducing the
> overall memory consumption. I certainly don't know what you do with your
> images in Lua but on the merits of simple memory consumption strings don't
> look so bad to me. Accessing values would be pretty fast too as all
> characters are from '0'-'9' with 3 characters per chanel and it's just a
> snap to convert "123" into 123.

I simply use Lua to specify the image . When the table with the data is 
assigned to the variable (a userdata) a newindex method takes over and reads 
in the pixel data into C memory using one byte per component so once the file 
is loaded there's no overhead whatsoever. It will take longer to load though 
since the file will be larger but thats not a big problem (I can always 
compress it or something). On the other hand having the pixel values as 
numbers instead of strings gives me the opportunity to perform arbitrary 
filtering on the image before actually shipping it to C and the same goes for 
any kind of data (audio, geometry). I could do the same with strings I 
suppose but I prefer the cooking and uncooking (that is from string to table 
and backwards conversion) code to be hidden from the user.

To the authors (mainly):
Trying to change the VM's register size gives me a lot of overflow warnings. I 
suppose the code has been written with a 32bit register stack in mind but it 
should be theoretically possible to change it to allow for any stack size (or 
power-of-two sizes at least). How hard would that be? If I try to work it out 
and add a REGISTER_STACK_SIZE macro in luaconf.h would you merge the changes 
into the main distribution? I'd hate to have to repatch every time a new 
version comes out and besides it wouldn't add any overhead by default and 
might be useful to others. Of course if one of you would be willing to do it, 
since you know the internals inside and out (as opposed to me), that would be 
even better.

Dimitris