I find that the suspend feature is so slow at saving down the current session that it's almost faster to shut down the VM and restart. Is there any way to speed up the VM suspend feature? Or are others seeing better suspend times than I?
No, of course not. But I assumed that suspend should be faster as it's not bringing the entire VM down. Right now I'm just shutting down and restarting but it would be nice to be able to suspend the VM and come back to where I left off.
if one compares Parallels suspend to VPC7's suspend, Paralell's wins hands down. It literally takes all of 3-5 seconds on the machine i have here which is more than acceptable to me. VPC on my previous powerbook @1.67ghz took well over 30 seconds to do the same thing.
It took about 25 seconds here on a Macbook Pro. That being said, I'm not disagreeing but I do see the OPs point. The latest version of VMware literally suspends a VM in 2 seconds.
Q emulator suspends in just a few seconds and reloads just as quickly. It does make a difference operationally. XP may load to the desktop in 10 seconds or so, but...it still takes another 20 to 30 seconds for all the services to startup. The suspend feature doesn't have this overhead. So yes, I too think that it would be better for the suspend feature to work faster.
I'm not sure what's up with my MBP, but it's ever slower than you guys are getting. I just timed a few ways to get down and back up and here's what I got: VM suspend: 1:22 (though it's usually faster than that ~0:30 or so) VM resume: 0:20 (the first time I resumed this VM after 2 weeks, it took 3-4 minutes) XP hibernate: 0:17 XP resume: 0:20 XP shutdown: 0:11 XP cold boot: 0:30 XP restart: 0:35 I think I'm going to stick with XP hibernation...
While the suspend feature isn't exactly fast, it is nice to be able to leave all my apps open and whatnot on the Windows machine, and bring them back automatically when I need them again.
I agree with this. I tolerate the suspend slowness for this very reason. I'm hoping that Parallels can do something to speed this up. Has anyone noticed if suspend takes longer based on the amount of memory given to the guest OS? -Will
For me suspend takes under 10 seconds. I have 2Gb of memory, but run the VM guest at 256MB and see no appreciable performance difference from 512MB. The larger the guest memory allocation, the slower the suspend process. Adam
suspend speedups While suspend performance probably isn't Parallel engineering dept's top priority at the moment, it does appear there is some low hanging fruit for suspend speedups. Doing an fs_usage while Parallels is suspending, you can see a lot of: 10:59:18 PAGE_IN 0.000008 Parallels 10:59:18 PAGE_IN 0.000000 Parallels 10:59:18 lseek 0.000002 Parallels 10:59:18 write 0.000035 Parallels 10:59:18 lseek 0.000008 Parallels 10:59:18 lseek 0.000003 Parallels 10:59:18 lseek 0.000000 Parallels 10:59:18 PAGE_IN 0.000003 Parallels 10:59:18 PAGE_IN 0.000000 Parallels 10:59:18 PAGE_IN 0.000000 Parallels 10:59:18 lseek 0.000002 Parallels system calls are rather expensive on OS X, and I would bet a lot of those lseeks can either be entirely avoided, or at least collapsed. The same thing for resuming from suspend, except with reads instead of writes. I've also noticed that Parallels makes an excessive number of stats to /private/var/db/.AccessibilityAPIEnabled. This is probably done by some higher level API call, but I'd imagine the interface would be much snappier if those calls were minimized.
It also appears Parallels is doing 16k reads and writes to and from the .sav file. ktrace yields: 728 Parallels CALL open(0xaf32d8,0x202,0x1b6) 728 Parallels NAMI "/Users/bbraun/Library/Parallels/win98/win98.sav" 728 Parallels RET open 18/0x12 728 Parallels CALL ioctl(0xe,0xc0185405 ,0xb011ad54) 728 Parallels RET ioctl 0 728 Parallels CALL ioctl(0xe,0xc0185405 ,0xb011ad54) 728 Parallels RET ioctl 0 728 Parallels CALL ioctl(0xe,0xc0185405 ,0xb011ad54) 728 Parallels RET ioctl 0 728 Parallels CALL lseek(0x12,0x4000,0) 728 Parallels RET lseek 16384/0x4000 728 Parallels CALL write(0x12,0x22f6a000,0x4000) 728 Parallels GIO fd 18 wrote 16384 bytes Using 128k reads and writes on OSX is roughly 30% faster for me, using the following test code: fd = open(argv[1], O_RDONLY); fcntl(fd, F_NOCACHE, 1); while( read(fd, buf, sizeof(buf)) > 0 ); I tested this on the same .sav file Parallels was reading/writing from/to. Sadly, ktrace omits timestamps, so it is difficult to tell exactly how much of an impact this would have on real word suspend/resume performance. Additionally, it is probable that those ioctls and lseeks can be avoided. However, it is probably also a result of Parallels using high level Carbon APIs. A slightly irrelevent, but amusing little tidbit from ktrace: 728 Parallels CALL open(0x582490,0,0x1b6) 728 Parallels NAMI "/proc/parallels/mem" 728 Parallels RET open -1 errno 2 No such file or directory It seems some code from the linux port slipped into the osx port. ;-)
