[sldev] Reformatting Textures for the cache

Dale Glass dale at daleglass.net
Thu Mar 22 04:21:38 PDT 2007


В сообщении от 22 марта 2007 10:49 Skal Tura написал(a):
> You are completely right on the MD5 vs UUID, wasn't thinking
> applicaton specific there.
> To save memory i would get rid of - chars and .tga :) not much, but
> even there's plenty of memory to fool around with, every byte still
> counts, don't do memory hogs, make efficient use of memory ;)
Bizarre. Seriously, it's pointless to save memory on this.

MD5 isn't an entirely bad idea if you want to have an integrity check, 
though. I notice that after crashing once, SL is likely to crash on 
startup, perhaps to something getting corrupted in the cache.

> Oh, and i'd prefer to use full blown MySQL but i haven't digged out
> would there be an efficient way of distributing and controlling it
> application specific. I know that some statistical software use it
> and has auto-installer and everything, but conflicts if you already
> have MySQL, and it needs to be 0-click thing for mainstream.
mySQL, and any RDBMS for that matter isn't any good for the purpose. 
Pretty much all of them don't deal well with large amounts of binary 
data, and you'd get very little benefit from them for something like 
this anyway. Plus, you're adding all the overhead of a RDBMS and get 
absolutely no benefit from it.

If you need a database anyway (for what? metadata?) just use BDB, 
which is nice and simple for that, and store the images themselves in 
files.

Some filesystems are crap and have horrible performance when you have 
many files in a directory, so store files like this:

/cache/6c/48/94/6c489466-3058-6475-6b1b-e5fc1d49f1f3.tga

>
> Can handling dynamic data within memory go much faster than what
> MySQL does? Ofc, building inside app would be more faster as no
> interfacing would be needed, but you get what i mean.
Not sure what exactly you mean here, but of course a specific solution 
would be faster than mySQL.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070322/8c4103a0/attachment.pgp


More information about the SLDev mailing list