[sldev] Cache speed experiment & results...

Felix Duesenburg kfa at gmx.net
Wed Jun 4 00:46:36 PDT 2008


Argent Stonecutter wrote:
> On 2008-06-03, at 17:59, Dale Mahalko wrote:
>> There are however filesystem limitations that may cause slowdowns, and
>> there may be diminishing returns at some point if only the local OS is
>> relied upon for huge caching storage. I would be interested to see
>> what performance gain is possible by have a dedicated slave MySQL
>> database running on the client PC when using a ridiculously huge cache
>> size..
> 
> My experience with storing big objects in databases is that filesystems 
> kick databases butts for performance when it comes to big objects. And 
> we're not talking about small files... even a 64x64 image is 16k, which 
> is getting into the range where databases start getting unhappy. A 
> 256x256 is definitely in the BLOB range.
> 
>> Windows isn't good at dealing with directories containing tens of
>> thousands of files.
> 
> Nobody is, so you store the texture for
> 
> 550e8400-e29b-41d4-a716-446655440000
> 
> In
> 
> $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on 
> linux, or
> %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on 
> Windows.
> 

I don't know where I read that... someone tell me if it's just a rumour. 
Can it be true that for reasons related to the historical evolution of 
Windows, it's still a wee bit faster if filenames sticked to the old 8.3 
convention?

If that is so, just break the filename up into parts with no more than 8 
characters. What we have here is simply the hex-ascii representation of 
a 128 bit number, requiring 32 characters to encode. The dashes are 
superfluous and can be omitted. Thus,
%CACHEDIR%\textures\550e8400\e29b41d4\a7164466\55440000.tga

Dismiss if this is rubbish.



More information about the SLDev mailing list