I really like Fancy Cache, I'll say that first. Windows still seems to be bloated as in how it manages memory and having a lot of memory just seems wasteful now. There aren't a whole lot of alternative caching schemes for Windows or even Ramdrives, it's great that you guys are developing ones that are good.
One of the things I notice, depending on which algorithm is being used, especially the frequent one, FancyCache seems to acquire junk over time that is rarely used. Like something that was cached in one scenario, but on average you rarely use it so it stays in memory because while it was used, it was used frequently. I don't know if FC takes this into account, but it would be nice if there was some sort of aging system so old or rare accessed content was removed, even if the frequency it is used at at one point was a lot (sort of a cross between the two algorithms).
It would also be nice to add a weight to certain directories or applications so they're more likely to be cached and prioritized.
Another consideration is allowing FC to cache your pagefile. I know it is possible to turn it off all together, but in my experience this can actually slow down the system and a lot of applications throw a fit if you don't have your pagefile on. Once again due to Windows being stupid at memory management.
Although this is personal preference, slowing down the graph in the statistics as well as having them run all the time in the background would be a nice addition.
Putting suggestions aside, I also had a question about the way deferred writing works. I understand how the reading cache works, but why does deferred writing operate off of a latency instead of total amount of memory you would want to use as a write cache? Of course with the more memory being used, the larger the risk of data loss as the drive can't put off writing data to the disk (basically functioning as a queue). I don't understand how just delaying the writes will yield higher performance as it will eventually need to write all the data regardless of it waiting.
Anyway, thanks and good work so far!
Few Suggestions
-
Axel Mertes
- Level 9
- Posts: 180
- Joined: Thu Feb 03, 2011 3:22 pm
Re: Few Suggestions
As of now the deferred writes seems to collect writes and overwrites of the same blocks until the set latency time is reached. Then the data is actually being written to disk.
This is helpful to minimize "wear and tear" on the SSDs, which have only limited write cycles, so it extends their lives.
IMHO we need a new optional mode for caching, that is optimized to reduce small writes and collect them to large writes reflecting on the disk block sizes etc.
We see dramatic performance gain on certain apps which are apparently not that well programmed and do lots of small disk I/O, especially writes. With the RAM cache this can be accelerated up to 5 times as I see it in some tests, which is hefty. The problem is that the current deferred writes algorythm does only wait for the latency time, not for the writes becoming larger chunks. The latter would be optimal.
With the current method of deferred writes we see total loss of the performance gain once the cache is filled faster than the latency, so the total end time is sometimes even slower/longer than without write caching. With a different algorythm this should be quite the opposite, as we have tested in our own apps with clever internal buffering before writing.
It will be interesting to read what support has to say.
Axel
This is helpful to minimize "wear and tear" on the SSDs, which have only limited write cycles, so it extends their lives.
IMHO we need a new optional mode for caching, that is optimized to reduce small writes and collect them to large writes reflecting on the disk block sizes etc.
We see dramatic performance gain on certain apps which are apparently not that well programmed and do lots of small disk I/O, especially writes. With the RAM cache this can be accelerated up to 5 times as I see it in some tests, which is hefty. The problem is that the current deferred writes algorythm does only wait for the latency time, not for the writes becoming larger chunks. The latter would be optimal.
With the current method of deferred writes we see total loss of the performance gain once the cache is filled faster than the latency, so the total end time is sometimes even slower/longer than without write caching. With a different algorythm this should be quite the opposite, as we have tested in our own apps with clever internal buffering before writing.
It will be interesting to read what support has to say.
Axel
Re: Few Suggestions
For your reference, here is the performance benchmark of the Defer-Write,
http://www.romexsoftware.com/en-us/fanc ... write.html
Defer-Write is not only to reduce write cycles, but also to boost the original performance.
@Axel: we roughly know what cause your issue when the cache is full. Will try to fix it in the next version.
@Bensam123: Alogrithm "LFU-R" has taken into consideration aging. FC caches paging files.
http://www.romexsoftware.com/en-us/fanc ... write.html
Defer-Write is not only to reduce write cycles, but also to boost the original performance.
@Axel: we roughly know what cause your issue when the cache is full. Will try to fix it in the next version.
@Bensam123: Alogrithm "LFU-R" has taken into consideration aging. FC caches paging files.
Re: Few Suggestions
Interesting...
Looking at benchmarks for this, curiously why doesn't FC and Ramdisk approach anywhere near the theoretical limits of memory subsystems? Is this because it would incur large amounts of processing overhead? Looking at bencmarks for a few Ramdisks in general they're all around the same.
http://www.raymond.cc/blog/archives/200 ... ite-speed/
Looking at benchmarks for this, curiously why doesn't FC and Ramdisk approach anywhere near the theoretical limits of memory subsystems? Is this because it would incur large amounts of processing overhead? Looking at bencmarks for a few Ramdisks in general they're all around the same.
http://www.raymond.cc/blog/archives/200 ... ite-speed/