3

I am making a drive image that will be deployed to several computers, and I'm tweaking it for performance. It is a Windows XP image.

Considering there is only one hard drive, will the machine gain performance if I place the Windows pagefile on a separate partition, possibly FAT16 (instead of NTFS as the OS partition)? I'm thinking of this because Linux does it, actually it uses the raw partition as "swap space", which is more performant (has faster I/O) than the default journaled filesystem (I expect FAT16 to be faster than NTFS too).

If this does make sense, how should I go about it? Another filesystem? should the partition be on the beginning or end of the HDD?

Improve this question
7
  • Why the downvote? It is a valid question IMHO, is not a dupe, is in the apropriate site, and I don't feel I'm saying something dumb (this is recommended in a couple of sites I saw, and I wanted to know). So please explain.
    – Camilo Martin
    Feb 2, 2012 at 17:20
  • performant is not a word
    – JamesRyan
    Feb 2, 2012 at 17:29
  • @JamesRyan "Dictionaries are descriptive, not prescriptive.". If "d'oh" (a la Homer Simpson) is a word already as per Oxford, performant will be (recognized).
    – Camilo Martin
    Feb 2, 2012 at 18:57
  • 1
    @JamesRyan Maybe it was pointless by having an explanation in brackets, but you can say "Linux is far more performant than Windows", and I doubt explanation is needed. Also, if it wasn't for you telling me it was not a word, I wouldn't know - it's everywhere! You're the first one I see complaining. It's jargon, just like "database" or "hyperlink".
    – Camilo Martin
    Feb 3, 2012 at 1:03
  • 1
    @JamesRyan Here, Oracle uses it too.
    – Camilo Martin
    Feb 3, 2012 at 1:15

6 Answers 6

Reset to default
9

There is no performance gain at all in putting your pagefile on a different partition on the system disk.

There is a gain, instead, in putting it on a different physical disk, but only if there are no other workloads on it.

Edit

To address your comment:

  • Compression is a Very Bad Idea for a page file, as it needs to be accessed precisely at random offsets, which becomes awfully slow if you don't know where a given sector is actually stored on disk and have to uncompress the whole thing first.
  • Fragmentation is never a concern, because the page file is always created in bulk and can't indeed be relocated at all (defrag utils always show it as a big non-movable chunk of data).
  • Whatever you can gain from a greater (theoretical) disk speed is useless if the disk is being accessed at the same time by other processes to read/write data or system files.
  • Ditto for any (theoretical) advantage of FAT above NTFS. Which is, by the way, purely theoretical, as NTFS is in no way as slow as you think it is.

Again: there is only one scenario in which moving a page file makes sense, and it's when it gets placed on its own physical disk.

Improve this answer
6
  • What about the performance of FAT vs NTFS? What about indeed using NTFS, but enabling compression (so that hopefully processor speed is traded for disk I/O)? Or, what about one end of the disk being faster than the other? (and also, a different partition would avoid the pagefile from getting fragmented over the disk).
    – Camilo Martin
    Feb 2, 2012 at 19:12
  • @Camilo: see edit.
    – Massimo
    Feb 2, 2012 at 21:19
  • Regarding the edit: Well, pagefile.sys can be defragmented offline, and I usually feel a difference after defragmenting it (it grows and fragments, after all) and the MFT... I've indeed thought initially NTFS must be slow, by comparing it to Ext4. Maybe this is indeed over-optimization. Thank you for your feedback and for answering the question.
    – Camilo Martin
    Feb 2, 2012 at 22:34
  • The page file can get fragmented if it grows dynamically due to memory pressure... but the first step for someone who's seriously concerned about performance is to make sure there is no need to grow it in the first place. If you are out of memory, you have far worse things to worry about than optimizing disk performance.
    – Massimo
    Feb 2, 2012 at 23:06
  • Also, setting it to zero size, rebooting the system and then creating a new page file is a lot quicker (and safer) than defragmenting it offline.
    – Massimo
    Feb 2, 2012 at 23:07
10

This doesn't make much sense. Also, by moving the pagefile off of the boot volume, you lose the ability for the OS to dump crash info in the event of a BSOD. This makes troubleshooting a pain. On top of that, I can't imagine that your performance would increase by any meaningful amount.

Just leave it where it is. If you're paging a lot, solve the actual problem by adding more RAM instead of mucking around with arcane disk layouts.

Unrelated side note: I really advise against new deployments XP. It's end-of-general-support and is within two years of ending extended support. Why wouldn't you be deploying Windows 7 at this point?

Improve this answer
3
  • 1
    I never used a crash dump to solve any BSOD, and I've solved quite many of them. Actually, I was personally never in a situation (or saw a situation) where it would make a difference between having or not a dump (I know what STOP 0x7B means, why I need a dump?). And I'm not in the position of telling people "go buy RAM or your PC won't work!". Would you install Windows 7 on third-world PCs with 512 of RAM? I just want them to make the best I can within that limitation. Besides, I'm asking because people seem to recommend it even if it is the same drive.
    – Camilo Martin
    Feb 2, 2012 at 17:36
  • 1
    Would you install Windows 7 on third-world PCs with 512 of RAM? - No, but I also wouldn't put XP on them either. If you're super-low on resources then a slim Linux distro would probably be the best fit rather than shoving out machines that won't have security patches in a couple of years. I never used a crash dump to solve any BSOD - Good for you. I have. Things like UNMOUNTABLE_BOOT_VOLUME are dead simple to solve. Plenty of others are not. The choice is yours, but generally speaking the gains are absolutely minimal at best anyway, so why push out a non-standard config?
    – MDMarra
    Feb 2, 2012 at 18:16
  • A slim Linux distro - perfect, for me (I've personally used SliTaz). But not for normal people, and I'm not going to try and convince them. Mind you, I've seen (nLited, tweaked to hell, etc) XP run on 128 MB of RAM, a 400MHz processor, and 3GB of slow HDD (and an AT keyboard). It was terribly slow, but it worked for the basic usage it was meant for. This is much better, and sincerely it is getting each step just a little faster, much better than a standard Windows 7 on 1GB RAM (and I still didn't have to disable visual effects or themes). The gains aren't "minimal".
    – Camilo Martin
    Feb 2, 2012 at 19:08
3

As others have already said, there is no performance gain. Quite the contrary, you can expect a measurable drop in performance. The reason for this is that by having the separate partitions on the same disk you will cause the head assembly to move more than would otherwise be the case. The effect is the same as a heavily fragmented disk.

This of course applies to anything stored in multiple partitions on a physical drive (or array) but is worse for a swap file because it is read and written to constantly.

Improve this answer
7
  • I cannot see how it could cause a performance drop, since the page file would anyway be on the same disk. I do not know how fragmented the virtual memory there gets, but I expect some chunks to be read sequentially (maybe this is not the case). After all, Linux still does it, so there must be a reason. I plan (in a future) to use former MS utility BootVis to inspect on that.
    – Camilo Martin
    Feb 2, 2012 at 22:36
  • @Camilo, for starters stop trying to compare Windows and Linux. They're completely different and do things differently. The similarities between the swap/page files on the two are superficial at best. I have already explained why you would get a performance drop, so I'm unclear which part you don't understand.
    – John Gardeniers
    Feb 2, 2012 at 22:55
  • @Camilo: the worst killer of disk performance is latency, which is caused by the disk heads having to actually reach the data they need to access. If the data are scattered across the disk, latency becomes the worst bottleneck; this is why fragmentation is bad. But if the heads have to continuously jump between files on two different partitions (say, system files on C: and the page file on D:), this has exactly the same effect as a heavy fragmented disk. this is why partitions are bad for performance.
    – Massimo
    Feb 2, 2012 at 23:10
  • @JohnGardeniers I'd like to know why a swap partition would be different from a partition with a pagefile. I'm curious, I tought a pagefile would be the same as a Linux swap in a file (and by default distros choose a partition instead of a file). What's different?
    – Camilo Martin
    Feb 2, 2012 at 23:46
  • @Massimo Then why does Linux not suffer from this? Also, isn't there latency anyway if it is in the same partition, considering it would in any case move the disk heads to where the pagefile is? My point is that in this case the pagefile would never be fragmented, and several sectors to read/write on it would be close together in the disk. I do not understand why jumping between two partitions would be different from jumping between two files on the disk.
    – Camilo Martin
    Feb 2, 2012 at 23:50
1

Since the beginning parts of the hard drive are faster than the end sections, I just set up a partition at the beginning of my hard drive for the swap file; named it Swap and set it to drive B:...

I have 8 gigs of memory, so set up an 8 gb partition at the beginning of the hd. I remember back when I had IDE hard drives, fat 32 was faster, so I set it for that also... don't know if that still makes a difference or not, these days.

I guess I might lose a ~little~ bit of speed at boot time, but if the swap file is being used by the os it should improve speed generally during use.

PS - with 8 gb of ram you can get away with disabling the pagefile, but I noticed a little bit of speed loss without one; since the pagefile holds all the most recently used files ready to load into ram.

Improve this answer
1
  • The bit about pagefile holding most recently used files is curious. Probably same thing would happen with hiberfile.
    – Camilo Martin
    Sep 7, 2016 at 14:31
0

Actually, there is one scenario where you may want to move the pagefile to another partition. A while back, I took over management of several older production servers that had a 3-disk RAID 5 container partitioned as C: and D:. Unfortunately, following a worst practice that was in vogue at the time, C: is only 8 GB, while D: is 128 GB. The space on the C: drive was close to being exhausted, and moving the pagefile was the only was to free up some much-needed space.

Improve this answer
1
  • 2
    Great, but how does your answer relate to the performance?
    – kubanczyk
    Nov 9, 2012 at 16:08
0

Actually there are a few reasons for doing this. What I typically do is research what the best practice is for that install (2012 is far different than prior, and prior they'd suggest different needs for machines with 32GB+ of memory to NOT do the 1.5x)

  1. Creating a partition at the lowest offset puts it on the faster part of the disk
  2. Forcing it to this partition at a fixed size prevents it from growing and fragmenting automagically

Both increase speed.

Improve this answer
1
  • Thanks, but at 32GB+, I'm almost sure you could even disable the pagefile...
    – Camilo Martin
    Oct 2, 2013 at 14:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .