Internet Temporary Files on SSD

[StarTech]

They are fine on SSD.

 

[Makaveli]

I store all my browser temp files on a Ram disc but as others have suggested using the SSD is fine.

 

[max789]

As much as I like Chrome, I really dislike the way it installs itself on my c drive without letting me change the destination drive, same goes for adobe.

I know there are ways around it but it's still a pita.

Chrome for Business allows installation on a non-OS drive.
http://www.google.com/intl/en/chrome/business/browser/

 

[behi]

No, for the umpteenth time, it doesn't. Windows may change the status of virtual memory to the paged pool, but it doesn't actually write those pages of memory to disk unless there is insufficient physical memory (there's a difference between a page in memory and the pagefile).

When you say Windows in general, you are dead wrong. Anything up to XP/Win 2003 really sucks at that and is way too aggressive at paging things out. What's worse, paging in happens one 4kb page at a time resulting in a giant amount of random I/O (where a traditional disk might give you less than 1MB/s). Try leaving Photoshop using a few GB of Ram running over night - waking it up will take an insanely long time (having a few GB of free Ram doesn't help).

Thankfully, that is fixed with Windows 7.

 

[Cerb]

Blanket statements like these are never a good idea.

+1

Read and take in all of this before you disable the PF:
http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

Like many features, dogma on both sides is wrong. Today, a good CPU costs more than maxing out most motherboards (32GB). Right up until Christmas of 2007, that was not the case. From 2006 to 2008, RAM prices dropped at least 90% (maybe more, but I specifically recall paying about $100/GB in 2006).

While many people have gotten along just fine without a page file, it is still recommended to have something available for legacy applications, and just for overall system stability, in case anything wants to use or expects the presence of such a file. In the end, a small amount of space taken up is inconsequential unless you are on really tiny SSD's.

And that is largely preference. I prefer to keep as little broken software on any computer of mine as possible, so I'd call that a feature, warning me to uninstall it and never use it (I have yet to encounter any such software, though). No software that expects a page file* is well written--worse yet, any software that tries to access it or manage its contents.

"You['re] slowing down your system by making a swap file."
I don't see how this can possibly be true. Yes, I know what a page file is for, and as you yourself stated, it is for when the system runs out of RAM. How, then, does your system slow down if you don't actually run out of RAM? Furthermore, in the event that your system DOES run out of RAM, how would not having a pagefile help (BSOD) or having it on a traditional HDD make it faster (it won't.)? I already have my page file set to a static size to cover my needs.

1. When was the last time a crash dump was useful? *crickets* It's really not something you use. It's something Microsoft anf vendors might occasionally use, when tracking down crashes that occur frequently for users in the wild, but not their internal computers.

2. Windows pushes out idle pages, leading to poor performance after an application has not been used in awhile. In Linux, FI, it is tunable, so you can have the best of both worlds. In Windows, there is no such option: leave the browser alone for hours, and even with plenty of RAM, it will be sluggish for minutes when you come back, due to random drive accesses for every action you take.

3. BSOD? See #1. You won't BSOD from running out of RAM; you just won't get a crash dump. I still have yet to see a non-overclocked Windows 7 system BSOD from anything but overheating or bad hardware, both of which tend to be easy to track down by means other than looking at a crash dump. I wouldn't even know how to go about utilizing a crash dump.

4. A static sized page file only gives you a crash dump as advantage, versus that much more RAM. If you're maxed out in terms of RAM but might be able to commit more, what else can you do? But, a system with 8GB RAM and 8GB PF is going to kill the application at around the same memory usage as with 16GB RAM and no PF.

You are also making large assumptions about my usage scenarios.
I process and edit large RAW files from my cameras in Lightroom and Photoshop on a regular basis, along with many other tasks. While I have made sure to have a good amount of RAM available (16GB) there may be cases where I may run out, especially if I am working on a RAW file with many layers. In extreme cases, one RAW with 7-8 layers can easily consume 6GB of RAM.

And if it crashes from running out of RAM, you might very well have lost money, am I right? That's a clear case for a big fast SSD and managed auto-expanding swap space, for any reasonable system. If the PF gets big, for that scenario, the best solution is to throw hardware at it--in this case, a bigger SSD, after you've maxed out your RAM.

* I don't mean RAM-hogging software warning you for CYA purposes; which IIRC, some Adobe software has done. I mean software that can screw up if specific paging behaviors do not occur, or which attempts to manage data in a page file.

 

[2is]

Just keep them on the SSD. I've had the corsair SSD in my sig for about two years with the OS, page file and temporary Internet files running off it and its still showing 100% health.

 

[Zxian]

http://www.tweakhound.com/2011/10/10/the-windows-7-pagefile-and-running-without-one/

There is so little performance gain to be had by disabling the pagefile (negligible at best), it's just not worth it to recommend it to people. If any individual wants to go about disabling it, they should know the potential benefits (save some disk space) vs the potential downsides (see above article related to software that needs a pagefile *cough*CS5*cough*). If a user is short on disk space, then reducing the size of the pagefile can help.

I have never fully disabled the pagefile on any of my Windows7 systems. If I leave my system idle for a while, it's just as snappy as it was before I left. I have not experienced the post-idle sluggishness that Cerb describes. Again, Windows 7 does not push idle pages to disk unnecessarily. If Cerb is experiencing long slowdowns after periods of no activity, then there's something else going on.

@Cerb - My previous HTPC was having bluescreen issues without any real rhyme or reason. Memory was stable, no overclock, nothing else. Turns out, it was a HDMI related video driver bug that had been fixed at one point and then reintroduced later. The bluescreens didn't point to a driver at all, and only gave a generic cause. The only reason why I was able to track this down was because I had a full memory dump available.


Regulars on "techie" forums such as this tend to forget that most people are not as "techie" as the regulars. Recommending that people disable the pagefile gives far more potential for issues and complications in future than leaving it on. If you tell an individual to disable their pagefile, you are doing so because your workflow and system usage allows you to do that without issue. My workflow has proved to me that having a pagefile (even a small one) gives more benefit overall than not having one. How many errors have people experienced by having a pagefile? My gut says it's far less than those who have disabled the pagefile.

 

[capeconsultant]

I would say that Cerb and Zxian have very clearly outlined the best arguments for each side. Nicely done gentleman. I have been following this argument for a decade or so.

The final answer is... "It depends".

 

[Cerb]

@Cerb - My previous HTPC was having bluescreen issues without any real rhyme or reason. Memory was stable, no overclock, nothing else. Turns out, it was a HDMI related video driver bug that had been fixed at one point and then reintroduced later. The bluescreens didn't point to a driver at all, and only gave a generic cause. The only reason why I was able to track this down was because I had a full memory dump available.

If they're occuring more than once, then it can easily turned back on, to be able to get a dump. As of the next BSOD, you'd have a dump.

Regulars on "techie" forums such as this tend to forget that most people are not as "techie" as the regulars. Recommending that people disable the pagefile gives far more potential for issues and complications in future than leaving it on. If you tell an individual to disable their pagefile, you are doing so because your workflow and system usage allows you to do that without issue. My workflow has proved to me that having a pagefile (even a small one) gives more benefit overall than not having one.

And that is why I like to go ahead and link to M. R.'s article series about it. The PF is part of a greater virtual memory system. Disabling it is largely for the case where its assumed good behaviors are not good for one's workflow, and the risk is none to neglible--and that there are no behavior tuning options. But, if that risks the case of you not being able to save hours of work, for example, it's a really bad idea. Likewise, you shouldn't think that just because you never see more X GB used, that you only need a small amount more than X GB to safely go w/o a PF. But, at the same time, there's way too much dogma and FUD out there, and virtual memory is not a mystical feature.

How many errors have people experienced by having a pagefile? My gut says it's far less than those who have disabled the pagefile.

Depends on how many ms you can go before a heartbeat, or other short local timeout (buffer for incoming GPS data, FI), lapses. In a pure throughput system, the answer will always be infinite, AKA no errors.

If MS would give even so much as a registry flag to tune it to never optimistically move data out of memory, until virtual memory started getting low, and preferably to optimistially move it back in, too, once it gets freed up, I would use a pagefile in Windows. With >=50% available, I shouldn't be seeing hard faults for application memory, nor their human-time-scale slowdowns, just because there are still vestiges of behavior choices from ancient times. It's not a bad feature to have, but I'm very much with Exdeath on it being a bad thing when a computer is slower than me (and, SSDs still aren't fast enough to make it unnoticeable).

 

[capeconsultant]

FYI, as I had not paid any attention to my pagefile settings in awhile, I went to check them. The setting was let windows handle it. To my horror, Windows had set the max to 16GB, my amount of RAM. That just seemed insane, so I set it to a static 2048. I SWEAR my Intel 520 SSD is now performing much snappier. Weird but true.

Maybe I'll go all the way and turn it off

 

[tweakboy]

That is if you have it on auto....... overall your waisting space by having it on when you have 8GB ram,, end of story

You will never even use 8GB let alone have a swap file,,,,,

 

[Hulk]

I put everything on my SSD; page file, temp files, browser files, photoshop scratch disk, etc. I use it heavily, and I still don't see my SSD wearing out before I replace it in 10 years.

Don't worry about it. Only thing is to just clear the temp files if you're running low on space.

Exactly.
A year on my Intel 320 120GB and the wear indicator is still at 100%.

 

[Makaveli]

Exactly.
A year on my Intel 320 120GB and the wear indicator is still at 100%.

i'm almost 3 years in on my 160 G2 and its still at 100%

tho my caches are on a ram disc as I posted earlier.

 

[Emulex]

a 320 running @ 200gb out of 320gb is going to last forever in a server bro.

"LOCK PAGES IN MEMORY" in 2008R2 does the job of not swapping out buffers if you must.