[sldev] Re: Reformatting Textures for the cache

[Skal Tura]

David Baker wrote:
> I couldn't disagree more.  In redesigning the cache system we must presume
> that the user we are writing for is running a hugely fragmented FAT32
drive
> and a file open in a 10,000 file directory will take 10,000 times longer
> than a file open in a 1 file directory (so maybe I exaggerate).
>
> Sorry to burst your bubble, but MacOS, Linux, BSD and all the rest are
tiny
> minority operating systems compared to Windows XP.  And will NTFS might be
> better than FAT32 for performance, Windows XP doesn't even encourage users
> to use it - FAT32 and NTFS are presented as equal options - so we have to
> presume that maybe 40-50% of SL users will be running FAT32.  Consequently
> any option that is non-optimal for FAT32 should be seen as a non-starter -
> which I suspect includes most direct file system options.
>
> If we want to rely on file system functionality we are going to have to
look
> at file-system-in-a-file solutions - perhaps using something third party
> rather than dusting off the VFS - but not relying on direct file system
> storage unless we can prove that that is the best option _on FAT32_.

You are DEAD wrong there.
Microsoft might not tell you which one to use, but FAT32 isn't an option
after a certain
size. I think 80Gb or something was the limit, in any case, in any of my
computers have i even
seen the FAT32 option in years! FAT32 is SO outdated that there hasn't been
new computers
for ages which use FAT32, not even my Fujitsu-Siemens laptop with 30gb hdd,
Athlon XP 2800+,
even the HDD was small enough for FAT32, it came by default on NTFS. And
that's lowend
laptop from some 3-4 years back.

Fragmentation: That's true, many run VERY fragmented drives, but come on! We
are saving some few hundred kb MAX files there, they aren't getting badly
fragmented, yes, the drive needs to seek from different portions for the
textures, but come on, big deal!

Users will never learn to defrag their harddrives, and using a filesystem in
a file would make it even worse, instead of thousands of small files, with
average fragmentation of something like 1.5-2.5 we would have a one huge
file with fragmentation of thousands!
With small files, there's atleast a chance that most of them won't get
fragmented ;)
Also filesystem-in-a-file solution has a lot of overhead.

That's exactly the thing which leads what current SL Viewer is:
 Heavy coding, lots of custom, innecessary complexities, which are neat as
ideas and would be good as standalone apps, honed and honed, but not as part
of a larger project (=lack of time to concentrate on bigger side-elements),
topping that off that it only works good on older hardware, making it slow
no matter what hardware you have.

 When you code something like a game, or close like SL, you need to keep the
future hardware in mind, not the past hardware! Look at any big name
engines, they have had their sights on future hardware BUT optimized it so
well and providing config options to make it work on older also. The funny
thing is, many performance things you do for newer hardware, also makes it
faster for older ;) Like multithreading ^_^
It's total crap that multithreading is useless, unless you have atleast
equivalent amount of cores.

Remember: Hardware is getting faster, not slower.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070327/408d5f86/attachment.htm