I had a play with Visual Studio 2010 last night to see what affect if any it would have with RetroCopy. While reading about their new optimizations I realized a setting I was using in Visual Studio 2008 could possibly be causing some hard to track weirdness (nothing major, just minor errors in sound generation and the 3D game room). So with that information at hand I benchmarked the MSVC10 build of RetroCopy and here are the results.
This is about an increase of 4% . The 64bit build saw a slightly bigger increase of about 5.5% . Not bad for doing nothing except switching compilers I guess, but I was hoping for more. 
I was going to release v0.940 today but I'm going to change one more thing before I do. And that is getting the core to level out CPU variations, this should limit any sound generation issues or "running less than 100%" warnings. I was doing it the lazy way before, assuming everyone would have a CPU that could push EVERY frame of the emulated system out quickly enough.
The issue is that time to time most systems have a struggle with some frames causing them to be take longer to generate than other frames. Over a second of time their CPU may be easily powerful enough to pump out 60 frames, but some frames within that time period may take longer than they should (1000ms/60 = 16.667ms allowed per frame). In this instance RetroCopy basically tells the emulator core not to wait so long next time to balance it out. But the way I'm doing it isn't that optimal, I need to keep track of more reference frames and balance out the difference in a smarter fashion (TM).
In v0.911 systems which can easily run RetroCopy still got a few warning messages and sound pops because of this issue when they shouldn't. So improving this balancing act will remove these messages and sound pops and make the experience a lot more smooth. This should only take an extra day or so provided it is smooth for my testers, so get ready for v0.940 , it's going to be faster and smooooother for you.