Linked by Thom Holwerda on Mon 11th May 2009 20:43 UTC
Windows SuperFetch is a technology in Windows Vista and onwards that is often misunderstood. I decided to delve into this technology to see what it is all about, and to dispel some of the myths surrounding this feature.
Thread beginning with comment 362983
To view parent comment, click here.
To read all comments associated with this story, please click here.
superstoned
Member since:
2005-07-07

Sorry, but I think you don't get it.

Superfetch loads things in memory it thinks you'll need. If you don't need it, no harm done - 'unloading' doesn't exist. Apps start as fast as without superfetch OR faster. Never slower. Same story with the linux memory management, expect that the linux one is less smart.

The only 2 ways in which superfetch could technically be a disadvantage are these:
- if the IO priority system is screwed, the reading superfech does COULD interfere with other activity. Depends on the quality of the kernel's management of priorities. No idea if this is an issue at all, I doubt it, but it is possible.
- superfech uses resources while your PC wouldn't have been doing anything if it weren't running. Bad for powerusage = environment and probably slightly bad for the lifespan of your hardware.

It might be true that the first issue I noted is actually real - but then the MS engineers writing this would've been rather stupid to forget about making the priority system work properly. Afaik that's not the case, so superfetch never slows anything down (but might not speed anything up either, depending on usage paterns and available memory).

The second - well, it matters on laptops and environmentalists I suppose. But that's about it...

Reply Parent Score: 2

WereCatf Member since:
2006-02-15

The only 2 ways in which superfetch could technically be a disadvantage are these:
- if the IO priority system is screwed, the reading superfech does COULD interfere with other activity. Depends on the quality of the kernel's management of priorities. No idea if this is an issue at all, I doubt it, but it is possible.
- superfech uses resources while your PC wouldn't have been doing anything if it weren't running. Bad for powerusage = environment and probably slightly bad for the lifespan of your hardware.


I can think of atleast one case where SuperFetch is a disadvantage: if you are playing a game the game will most likely read its files in more-or-less sequential order, and disk cache will load the parts of the files it assumes will be needed next. But if SuperFetch is caching something in the background while you're playing then it'll invalidate the disk cache causing slightly longer loading times.

Now, I'm not saying that's a big issue though. It's most likely negligible enough for most people not to care. I just mentioned it for the sake of argument.

Reply Parent Score: 3

superstoned Member since:
2005-07-07

Well, yes, it is a valid issue. Caching algorithms would probably be a bit bad to not take such a situation into account, but when low on memory it might happen.

Furthermore, from the threads below I understand the IO priority system in windows isn't at the level of quality it would need to be to prevent prefetch from having an adverse effect on the performance of the system. In other words, the first disadvantage I considered so unlikely seems to be hurting users...

Reply Parent Score: 2

segedunum Member since:
2005-07-06

Superfetch loads things in memory it thinks you'll need. If you don't need it, no harm done - 'unloading' doesn't exist.

Managing memory in any way is expensive. You have to manage that cache. Nothing is ever cost-free.

Same story with the linux memory management, expect that the linux one is less smart.

This is nothing like Linux memory management. Linux traditionally keeps a cache because memory is wasted if it isn't used. Old pages are paged to disk cache regularly. So far, so good. What Superfetch does on top of that is to 'intelligently' preload applications into a cache it thinks that you'll need at startup and as it's running. That's an expensive operation from an I/O point of view that is not guaranteed at all to help you at any given time or any given application you might be using. Preload for Linux faces all the same unreproduceable issues and questions of whether it makes a real difference to a user's overall usage. Hell, Linux's caching alone still has some extreme corner cases.

With Linux, if you load something once and then again and it is still in the cache then great. Things will be faster. However, it does not attempt to constantly fill and manage the cache based on its idea of what your usage pattern is. That's the key difference. In theory, it would be great if you could get that right which is why people think this is such a great idea but in practice things are very different.

Besides, with any form of caching the central point stands and this certainly stands with an additional service over and above caching such as Superfetch. You need plenty of 'free' memory over and above what applications you use to make it work. It's fine when you can put 'free' memory to work but it's not fine when you don't have it which is often the case on desktop systems. Whereas the cache itself might be relatively cost free given the benefits, if you start sticking a service on top that decides what should constantly be in the cache then you get a whole bunch of real unknowns.

It's not really the technological idea that is at fault with Superfetch. It's the idea that it knows what your usage pattern is, it knows what you'll be running in the future and the algorithms responsible for deciding it.

Reply Parent Score: 2

JeffS Member since:
2005-07-12

"Superfetch loads things in memory it thinks you'll need. If you don't need it, no harm done - 'unloading' doesn't exist. Apps start as fast as without superfetch OR faster. Never slower. Same story with the linux memory management, expect that the linux one is less smart."

Nonsense. The way Linux uses caching is much, much smarter, IMHO. It does moderate caching, leaving much of the system RAM free. This means less disc I/O, less flushing, less paging, but also faster load time for common apps, and faster access time for common data.

SuperFetch just tries to use as much unused RAM as possible. While the idea "unused RAM is wasted RAM" sounds decent in theory, in practice it's not. Trying to purposely use up unneeded RAM just causes more activity, more disc I/O, more paging, and more flushing (when less common stuff is started). It also drains battery life on laptops faster (more stuff going on).

And of course, no caching is a bad idea, too. Caching, in a lot of areas, has proven to have speed benefits.

Thus, the middle ground is the way to go. Linux takes the middle ground. SuperFetch takes the extreme ground of caching and using as much memory and disc I/O as possible.

And the funny thing is, Linux, with it's more moderate caching, and it's utilization of less overall resources. is much much much faster, and loads apps like Firefox, Eclipse, OpenOffice, QtCreator, NetBeans, GIMP - all cross platform apps) a gazillion times faster than Vista with Superfetch.

Reply Parent Score: 2

kerframil Member since:
2005-07-13

"Superfetch loads things in memory it thinks you'll need. If you don't need it, no harm done - 'unloading' doesn't exist. Apps start as fast as without superfetch OR faster. Never slower. Same story with the linux memory management, expect that the linux one is less smart."

Nonsense. The way Linux uses caching is much, much smarter, IMHO. It does moderate caching, leaving much of the system RAM free. This means less disc I/O, less flushing, less paging, but also faster load time for common apps, and faster access time for common data.

Now that is complete nonsense. Linux will gladly consume almost all available physical RAM for its pagecache. Case in point ... I have a Linux 2.6.28.9 system with 8G of RAM which has been up for 11 days. It currently has only 69M of RAM unused, with 637M used by applications, 523M used for kernel buffers (largely attributable to the ext4 inode cache in my case) and 6750M cached! In other words, the pagecache grows as large as it possibly can and that's a good thing.

That it does not on your PCLinuxOS system is due to an insufficient workload being generated for the pagecache to ever consume the majority of your available RAM and/or the kernel not running long enough before being shut down.

And, guess what, Windows works in the same way and there's nothing wrong with that. Indeed, it's hugely beneficial and the reason why a RAM upgrade yields immediate performance enhancements (even beyond the scope of providing for any especially memory hungry applications that may be used):

http://en.wikipedia.org/wiki/Page_cache#Memory_conservation

As the original poster alluded to, SuperFetch is a different kettle of fish. By virtue of the very nature of SuperFetch, the comment that the Linux VM is "less smart" is correct, as there is no equivalent to SuperFetch (please also note that "less smart" does not mean the same thing as "ineffective"). However, one could argue as to whether SuperFetch is worthwhile which, ultimately, is the topic under discussion here ;)

Reply Parent Score: 1

malxau Member since:
2005-12-04

...If you don't need it, no harm done - 'unloading' doesn't exist. Apps start as fast as without superfetch OR faster. Never slower.


This story is full of comments by people indicating that it can be slower. Note that if an app requests 200Mb RAM, the memory manager still needs to walk along the standby list discarding prefetch data page-by-page, so it's more accurate to say "SF data is not written back to the pagefile", but it still needs to be unloaded.

if the IO priority system is screwed, the reading superfech does COULD interfere with other activity. Depends on the quality of the kernel's management of priorities. No idea if this is an issue at all, I doubt it, but it is possible.


If the priority system were not screwed, it could still be bad. In theory, low priority IOs should be issued to disk on a 1-in-20 basis when normal priority IO exists. If your normal pri IO is sequential, that low priority IO can still trigger a seek and slow it down.

And yes, IO priorities are far from perfect. In Vista, no priority boosting was performed if a regular priority thread was waiting on activity performed by a low priority thread. It could stall on a collided pagefault (needs the data prefetch is fetching) or on any lock in the IO path (prefetch has a lock held, issued low pri IO that takes seconds to complete, and the foreground apps wait for the lock.)

In Win7 boosting is implemented and will be performed if a normal pri thread waits on many common locks (but not all) held by a low pri thread.

superfech uses resources while your PC wouldn't have been doing anything if it weren't running. Bad for powerusage = environment and probably slightly bad for the lifespan of your hardware.


That's inherent in the design of SF (use background cycles to load things.)

It might be true that the first issue I noted is actually real - but then the MS engineers writing this would've been rather stupid to forget about making the priority system work properly.


(Disclaimer: I am an MS engineer who worked on making the priority system work properly, but have not worked on SF itself.)

To be fair to the SF crew, Vista was finished under considerable time pressure. Changing every lock in the IO path to be low priority aware is a huge job. They were faced with the choice of shipping with no IO priority, shipping with IO priority in the disk scheduler that can invert in higher levels, or spending years making it perfect. They chose the middle option, presumably as a compromise. It still gives some benefit, but also has some inversion problems. Their choice doesn't make them stupid - it made sense at the time. Resources are always finite.

Reply Parent Score: 1

superstoned Member since:
2005-07-07

To be fair to the SF crew, Vista was finished under considerable time pressure. Changing every lock in the IO path to be low priority aware is a huge job. They were faced with the choice of shipping with no IO priority, shipping with IO priority in the disk scheduler that can invert in higher levels, or spending years making it perfect. They chose the middle option, presumably as a compromise. It still gives some benefit, but also has some inversion problems. Their choice doesn't make them stupid - it made sense at the time. Resources are always finite.

Well, stupid is of course a bit harsh but considering the amount of complaining it probably should've been off by default until a servicepack would have fixed the most serious performance regressions. Either way, thanks for the information... I'll by trying Vista today on my new laptop. If it performs smooth enough I might keep it on there (after installing KDE 4 of course) instead of replacing it with linux right away ;-)

Reply Parent Score: 2

Fergy Member since:
2006-04-10

Their choice doesn't make them stupid - it made sense at the time. Resources are always finite.

That would make sense if you are a small startup that needs to release the product or go bankrupt. But the biggest OS maker with 95% marketshare needs to cut features after 6 years of development?

Reply Parent Score: 1