I've read that for audio/video work a swap size of twice the RAM is recommended; however, when I loaded up 92% on my 1 GB machine it ran fine until I hear the hard disk do a swap, and then things froze. Given that, zero might be the best bet. We never want our sample heads to page onto the disk. As long as un-needed processes are not running and you leave some memory for the OS, zero should be good.
I haven't tested with zero yet. I still have 2GB set on my machine.
I could hear the heads on the disk do a big seek while I wasn't doing anything. The OS just decided it wanted to store a bunch of data to disk.
I remember hearing that all the time back in the days of 4MB and 16MB RAM systems. I'd be editing some graphics, then wham! the whole system would slow down while the disk went nuts.
I assume that it was paging anyway. I can't think of any other reason that the OS would randomly access the HD when my RAM was loaded to the gills and I wasn't doing anything else. Then again, who knows what the Redmond Geeks have going on in the background!
Anyway, Giga locked up, but I was able to exit. Msg32 still had some RAM allocated, and I wasn't able to restart Giga. A quick reboot and I was back on the road. I haven't tried loading over 90% memory since, but I've gotten close. The problem only occurred once.
I'd imagine with 2 GB of memory that you would probably want to not have a swap file. You definitely don't want the attack portion of the samples to swap to the hard drive. I've run into this in Kontakt which just caused pops on playback. They added a switch to lock the memory so the swapping doesn't occur. Don't know if this feature is already in Giga 3 or not.
GigaStudio 2.5 "locks" all the samplehead buffers, so that they cannot be moved in Ram memory or swapped to disk by the VM system. I guess Gst3 uses the same approach.
Locking significant amounts of memory, btw, makes Gigastudio a "bad behaving app", from a software engineering viewpoint. This is one of the reasons why it takes soooo long to load Gig files and performance setups.
I would use a swap file of 512 Mb or smaller. You don't have to apply the typical rules of thumb, as you are only running 1 app and the OS. Furthermore, Gigastudio will hardly invoke any disk swapping (maybe for it's Exe and Dll files). The normal rules of thumb assume that you run multiple (Office) apps, accessories and OS utilities at the same time, making it difficult to predict peak versus avarage memory load.
I've been using 500 MB on my 1Gig system, never had a problem (GS 2.5 for over a year, or GS 3.0 for a week or so). Windows claims it needs 1.5 Gig, but imo that's a very out of date calculation for these big memories.
Since you have a keen ear for hard drive activity (and are a PC guy it seems) I was wondering if there are any OS drive accesses while GS is running i.e. playing samples (assuming no paging is occuring)? Isn't all of XP and GS loaded into RAM when each is launched? I am wondering about this since we always say not to put samples on an OS drive but if there is no OS drive access when GS is active, samples on the OS drive would seem reasonable. Thanks.
There is no WRITE access of swapped ram from gigastudio, I think, but there is definitely read access from the disk. It seems to reserve a place for enough buffered samples in memory, and then fill the memory as needed (but not swap anything out).  re-reading, I see your point better -- if NOTHING accesses the system drive, why not use it for samples ... hmm, maybe so. My samples disk now has 57 Gigabytes, and there's plenty of space on the system drive doing nothing. Maybe Jon or others will provide more information.
I agree with Peter that Giga memory should be programmed to never move anything to the HDD. I see three possibilities as to what happened on my system...
1) Giga sample heads were moved to the HDD (unlikely)
2) Some Windows componet was moved to the HDD (likely)
3) I had some other process hit the hard drive (virus? spyware? I hope not. It was after a clean SP1 install.)
I think the suggestion of a 512MB page file is reasonable. I set mine to zero last evening with no ill effects. I ran over 70% RAM load for some hours on my 1GB machine.
There is more information about these topics on David LaBorde's tweak page part 1 and part 2.