With 4GB RAM, do I still need Windows page/swap files?

[Nothinman]

Strictly speaking Virtual Memory is always in operation and cannot be ?turned off?. What is meant by such wording is ?set the system to use no page file space at all?. This would waste a lot of the RAM. The reason is that when programs ask for an allocation of Virtual memory space, they may ask for a great deal more than they ever actually bring into use - the total may easily run to hundreds of megabytes. These addresses have to be assigned to somewhere by the system. If there is a page file available, the system can assign them to it - if there is not, they have to be assigned to RAM, locking it out from any actual use.

Generally allocations are done in a lazy fashion, meaning that you request, say, 100M worth of addresses and the system goes "Ok, sure" but doesn't do any real allocation. Once you start touching those addresses soft page faults will happen and the system will actually start allocating the memory and putting your data into it. So not having a pagefile available shouldn't have any affect on your ability to allocate memory that you're not going to use unless there's some checks or limitations in the NT kernel to prevent that. I know Linux lets you tweak how it handles overcommit but I'm not 100% sure about NT.

My point is, let's take a system with 1 HD, 1gb of memory, and XP running Photoshop. When you reach a point that the I/O on that single disk is dealing with the OS pages and also with Photoshop paging and manipulating a 10gb graphics file that is also on that same HD, you will likely see a slow down. So, if you add a seperate HD or HDs, you can manually distribute the paging or virtual memory space to drives that are not burdened with the OS.

Generally there is no I/O burden from the OS unless you start using parts of it that aren't already loaded into memory. Once something starts it and all of it's shared libraries will stay loaded into memory until it exits or memory is so tight that the kernel decides to evict it from memory.

But I'm not arguing that a separate physical drive for a pagefile in a memory anemic system won't be helpful. But seriously, if you're trying to work on a graphics file that's 10x larger than the amount of physical memory in the system you're going to expect slowdown no matter what.

So, I am not talking about if the page file will be used or if the OS or Photoshop manages the virtual memory space. My point is, that it does make sense to be able to relocate it and optimize it. Even Microsoft has how-to's on page file optimizations and suggests multiple drives.

To be pedantic the OS always manages virtual memory since userland processes never get to see the physical memory addresses. MS also has documentation that misuses the term 'virtual memory' and even some that contradict other articles because different docs were written by different people with various levels of knowledge.

For the most part you shouldn't even really be worrying about the pagefile, just let the OS handle it. If memory really is tight then moving it to it's own drive might help but it won't have anywhere near the affect of adding more memory.

This was semi-rhetorical. Of course they want to allow the user to be able to configure the page file for the same reasons MS allows and supports it.

But they shouldn't. One would think that they would rather offload that support to MS by just using the standard memory management facilities inside of Windows. All Adobe is doing by managing their own scratch space on top of the other memory management they have to do is adding more complexity.

 

[Nathelion]

Well.... If you set the Windows page file to your i-ram, and adobe didn't have the "scratch file", your stuff would end up either in RAM or in i-ram anyway. Aka, since system memory is fully virtualized anyway, Adobe trying to make their own virtual memory doesn't make much sense.
The one case in which i guess it would help is if your i-ram is too small to hold the "regular" pagefile data and the photoshop data at the same time... which seems pretty unlikely seeing as how, at least in my case, pagefile usage pretty much never goes over 500mb. So theoretically there could be a benefit, I just doubt that it works very well in practice.

Edit: When I think about it, the scratch file might make sense in terms of reducing virtual memory usage. Data that is sitting on the disk does not require virtual address space... Data sitting in the pagefile does. So virtual memory usage would go down since photoshop essentially makes access to that data a matter of I/O instead of memory.

 

[Yellowbeard]

OK, here's an open ended question/scenario. Let's say you have a work station with 4gb of physical memory and a 64 bit OS that can address all of it. This system has a single system HD and a single data drive. If you are actively manipulating 10gb files with Photoshop would you rather try to have the inevitable paging/swapping occur on:

A: The system drive?
B. A 7200 RPM dedicated page drive?
C. An I-RAM?

Remember, Windows will never relinquish that last bit of RAM it needs for......whatever. So, technically speaking you'll have slightly less than 4gb of memory for OS and the apps to fight over. I know people that use these setups and it works. So, whatever problems or fundamental reasons there are for not allowing the optimization of a page file or Photoshop swap file, the performance outweighs it. I hate to sound like a blind sheep but I don't think both Adobe and MS are wrong here. C is better than B and B is better than A in the situation above.

 

[Nothinman]

Edit: When I think about it, the scratch file might make sense in terms of reducing virtual memory usage. Data that is sitting on the disk does not require virtual address space... Data sitting in the pagefile does. So virtual memory usage would go down since photoshop essentially makes access to that data a matter of I/O instead of memory.

You have that backwards. Data in the pagefile is managed by the kernel so any data structures needed to keep track of it will reside in the kernel's address space and not affect the process' share while data in the scratch space will have to be managed by the photoshop process and thus will eat up some of it's address space.

C is better than B and B is better than A in the situation above.

No doubt. But even though you'll have split the load a bit you'll still have paging happening to/from all of the drives anyway.

 

[pallejr]

I think what he is trying to say about the scratch file is that photoshop can use it a bit like you use AWE. You can work with more data than can be held in the virtual address space at the same time. If you only go with the pagefile, you have the 2/3 GB limit

 

[Nothinman]

I think what he is trying to say about the scratch file is that photoshop can use it a bit like you use AWE. You can work with more data than can be held in the virtual address space at the same time. If you only go with the pagefile, you have the 2/3 GB limit

Possibly, but that's only conjecture because you have no idea how photoshop uses the scratch space.

 

[pallejr]

http://kb.adobe.com/selfservic...lId=kb401088&sliceId=1

says it gives up to 64 exabytes of virtual memory in CS2

 

[Goldfish4209]

If you're confident that you're not going to run out of your 3.2Gbs of memory, you can try running without a pagefile, which I'm doing with vista x64. It works fine, but I don't do any photoshopping and just play moderately taxing games like bioshock and FSX.

 

[Nothinman]

says it gives up to 64 exabytes of virtual memory in CS2

Actually no, it says that the scratch disk is similar to virtual memory and that it supports up to 64EB of scratch space. The article also misuses the term virtual memory every time it's used so it was probably written by a technical writer who doesn't really understand photoshop internals or virtual memory management.

 

[Modelworks]

I'm still waiting for adobe to release a 64 bit photoshop client.
Its annoying having to use the hard drive at all when editing large images and running into the memory limitations of 32 bit.

Adobe has the check for 64bit flag set on its programs but its not exactly the same performance wise.

 

[pallejr]

Originally posted by: Nothinman

says it gives up to 64 exabytes of virtual memory in CS2

Actually no, it says that the scratch disk is similar to virtual memory and that it supports up to 64EB of scratch space. The article also misuses the term virtual memory every time it's used so it was probably written by a technical writer who doesn't really understand photoshop internals or virtual memory management.

Yes, that is what the article says. So when it says it can use such a large scratch place, then it must also be able to unload and reuse the space in the "real" virtual address space for other things, hence the "AWE" comparison.

 

[Nothinman]

Yes, that is what the article says. So when it says it can use such a large scratch place, then it must also be able to unload and reuse the space in the "real" virtual address space for other things, hence the "AWE" comparison.

Yes, which has no affect at all on the available amount of virtual memory. And they would no doubt be better off using Windows AWE API since it's likely to be better tested and supported.

 

[pallejr]

We are going in different directions. AWE was just a comparison, and is only about physical RAM.

It was about the pagefile. If photoshop only used the normal API functions to allocate memory, it would be limited to the user space windows sets a side to it. By making an internel virtual memory system, it can grow way large, because it can reuse the 2/3 GB user space.

 

[Nothinman]

It was about the pagefile. If photoshop only used the normal API functions to allocate memory, it would be limited to the user space windows sets a side to it. By making an internel virtual memory system, it can grow way large, because it can reuse the 2/3 GB user space.

It's still limited to the VM limitations of the architecture, use of AWE or scratch space can't change that and the use of an internal VM emulation thing will hurt more than help because it takes memory and thus address space to manage that space. The photoshop process can never grow larger than the 2G or 3G of VM provided no matter how many little tricks Adobe tries to employ.

 

[pallejr]

I know it cannot grow lager than 2/3GB, hence the word "reuse". If photoshop didn't have an internal reuse-system, it wouldn't be able to work with more than 2/3 GB of data. AWE is also such a system, it just uses real RAM instead of scratch file

 

[Net]

believe it or not you won't see a time where you won't need virtual memory any time soon.

 

[Nothinman]

Virtual Memory, true. Pagefile/swap space not so much.