This is JUST for scripts saved (compiled) in mono (not the old LSO).
In full disclosure, I'm not thrilled with this script. It works, it's just not as fast as I was hoping it'd be.
Basically, here's the deal. In mono, strings use a character encoding known as UTF-16. With this encoding, the vast majority of characters are 2-bytes each. In rare cases, they are actually 4-bytes each. However, there's NEVER a case where a character is a single byte (not even for something as simple as "A" or "1"). Therefore, if all of our strings are ASCII (basically, the keys on a USA-style keyboard, with a few extra "control" characters), we're almost always wasting one of the two bytes in our UTF-16 characters. ASCII always/only takes one-byte-per-character.
In the LSL wiki (seen here, http://wiki.secondlife.com/wiki/User:Becky_Pippen/Text_Storage) there are compressAscii and uncompressAscii functions. However, they're as slow as molasses, taking 3 or 4 seconds just to compress/uncompress a simple "Hello World!" string. The main reason they are slow is that they jump through all kinds of hoops using the llEscapeURL/llUnescapeURL as well as Base64 stuff.
For years, all of this has been a point of frustration for me. And then, recently, it dawned on me that 127 * 127 * 2 = 32258. What's that have to do with anything? Well, all-told, there are 127 characters in ASCII (128 if you insist on counting 0x00). So, if we could figure out a way to "pack" two ASCII characters into a single UTF-16 character, that would make for 127 * 127 unique possible UTF-16 characters. And since each UTF-16 character always takes 2 bytes, that's the * 2. So, to cover all the cases of two ASCII characters packed into a single UTF-16 character, in mono, we'd need 32258 bytes of memory. With our 64kB limit, we'd only be using half of it.
So, my idea was that llSubStringIndex and llGetSubString would be MUCH faster than all the llEscapeURL/llUnescapeURL & Base64 stuff that the wiki scripts were doing.
Because I have to build that large 32258 byte string, it takes my version about 5 minutes to initialize. However (unless reset), it only has to do that once for the lifetime of the script. And then, we get MUCH better performing ASCII compression/uncompression. (I actually called my functions CompressAscii/UncompressAscii.
So, that's the idea, but it's still not lightening fast. It's MUCH faster than the wiki version (maybe around twice as fast). However, if you stuff a long string into it, it still takes a few seconds to process it.
Therefore, I'm not sure it's fast enough to do something like build all the strings for the title and buttons of llDialog, but maybe some people can get some use out of it.
Everything is full-perm, and please examine the Test_Of_Ascii_Compression script for examples of how to use the actual lslAsciiCompression script.
Best Regards,
Kyle
