1. 

   pyromaneyakk
   Member

   This idea is primarily for gaming, though it may affect other applications. Many games use large archive files for storing media resources. While these files are large, they are often accessed in a random fashion. Sometimes there may be a single PKG file that has almost all of the resources for an entire game. This will be passed up by caching systems like Eboostr and ReadyBoost because it's assumed that large file == sequential access. I would propose that max file size can be specified, and possibly based on mask and/or path. This will allow users to restrict most of the files in cache to very small files, but selectively load certain very large files known to be content archives.

   I am curious if anyone else has input on this?

   Posted 1 year ago #
2. 

   Andrey Zarudnev
   eBoostr Team

   By default there is no file size limitation that can be cached and you can set such a limit using "Settings.ini" file (no mask or path dependency--one for all.)

   Add your game to Priority list and this large file will be most probably cached :)

   Posted 1 year ago #
3. 

   pyromaneyakk
   Member

   There is one key to this idea though -- if you set a global max file size, then you will end up potentially caching a lot of commonly-used but large (and therefore not necessary) files that would not benefit from the high random-access speed of SSD. For instance the SSD I am currently using is a 40GB Kingston (Intel-made) which is not super fast for sequential access but supposed to have random access above 50MB/s (haven't tested myself). If there are EXE, DLL files over for instance 1MB (some games etc. have EXE's and DLL's 10+MB), I may not want those to be loaded by SSD since the sequential speed is similar to my mechanical disks. But if I have a ZIP / PAK / GCF etc. file that's 1GB and contains thousands of small files (models, material definitions, scripts, etc.) that would benefit much more from the cache.

   This is just a thought though -- as it is Eboostr 4 Beta is providing a major boost in load times for most applications. Another simple way to do it, rather than having specific file size definitions for various extensions, would be to have a "archive types" list that would allow requested extensions to be exempt from the size limit. That would probably be much simpler to do in the short term, since it wouldn't require a way of associating the extensions / masks with arbitrary numbers and a means of handling the comparisons on cache building.

   Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.