[sldev] Reformatting Textures for the cache

[Dale Glass]

В сообщении от 22 марта 2007 17:54 Dzonatas написал(a):
> The reason to use SQL (or whatever) database over a direct access
> to the filesystem is the eliminate the overhead of the filesystem
> and disk fragmentation.
A RDBMS will get you TWICE the fragmentation.

Level 1: Fragmentation inside the database's data store
Level 2: Fragmentation of the database's data store on the disk

RDBMS do very much get internal fragmentation, and are quite a pain to 
defragment. For example see:
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx#EJD

If you want less fragmentation then go with the "uncompressed images 
in fixed size areas" method. Then you allocate space once in a few 
very large files, defragment once, and have no fragmentation inside 
those files.

But as Tofu noted, uncompressed files are very easily a way to become 
I/O bound, and storage speed grows a lot slower than CPU speed. Some 
compression would actually speed things up.


An alternative would be the fixed size store above, plus compression: 
You have a 16 bit 512x512 image? That's 512KB. Add say, 16KB for any 
metadata and overhead. Now take the image, compress with say, PNG and 
put it into the slot. You'll pay for this with a huge waste of disk 
space, as you'll likely get things like 32KB images in 528KB slots, 
but fragmentation won't be a problem.

But then you'll pay for this yet again: This reduces the effectiveness 
of readahead. If you have the 32KB of data, 496KB of junk, then 
another image. If they were stored continuosly, then readahead would 
read something useful.



>
>
> I haven't really had to defragment my drive until I started to use
> SL. Because before SL, the idle process to defragment the drive
> kept up just fine.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
-------------- 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/119774ab/attachment.pgp