[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