Vectors v. Hexadecimal

Is a hexadecimal more memory efficient than a vector?

If a script has a stack-heap collision and no one is around to read it, does it still print an error?

Bobby, I'm not sure I understand your comparison between "vector" and "hexadecimal." One is a datatype consisting of 3 floats and the other is simply a system of representing numerical values. Are you referring to the difference between a vector whose components are presented in decimal as opposed to hex? e.g.:

< 16, 32, 64 >
vs.
< 0x10, 0x20, 0x40 >

If that's the case, both use the same amount of memory. All numerical values, whether expressed in your source code as decimal or hex, are ultimately stored only in binary after compilation.

If that's not what you were asking, please elaborate.

Ok, after looking at your previous posts, I see you're probably referring to hexadecimal color vs. vector color representations. Since a color value ultimately ends up as a 32-bit integer value (including the alpha component), yes, colors can be stored as integers which will take up less memory than vectors.

But as Void tried to point out in the other thread, if the color value is to be applied in lsl, and unless you're *really* in danger of smacking stack into heap, it's probably more efficient just to store the vector. In order to be of use, you'd have to use some memory for bytecode to translate from integer to vector, which will require some usage of sim resources to process the conversion. 3 shifts*, 3 masks, 3 divisions. (Add one of each if you're also storing alpha.) Sometimes, optimization ain't.

I ran into something similar when I thought I could save some memory by replacing several integers used only as boolians (TRUE/FALSE) with a single integer whose bits I would twiddle. Turned out that by the time I'd re-vamped the code to evaluate, set, and toggle individual bits, rather than whole integers, I'd used up waaaay more memory than I was "saving".

[*Edit: Ok, only 2 shifts... unless you're "storing" an unused alpha value in the LSBs]

I store rgb values in 2 letters, 12 bit in base64, 4 bit per color value are accurate enough.
Or srote 15 bit in one UTF8 letter (that counts as a double letter for values >125).

This only makes sense if:
- You have a base64 or utf8 to integer converter used in your code anyways, also for other reasons, or if you just convert a lot anyways. (converters eat data, too)
- You store a lot of data, at least 2-3 integers per list.
- Your code does not need to convert, read or write data every second (because conversion takes resources and time). It just needs a large database and large cache (to make it worth a compression).
- You read a LOT of data from notecards, that big, there are too many lines to bug the dataserver with, or the data would be larger than 64k (notecard size limit) if uncompressed.
- You use the mono-compiler, it runs procedures faster and has more memory for code.
- You want to store as much data in a prim name or description as possible (this is bugged in actual clients).

When it DOES make sense is when you want to store a lot of keys, like storing a key in 2/3 as much data in base64 or storing a key in 5/9 as much data in UTF8.
Im talking >250 keys.