NCrunch will create as many workspaces as it needs to meet the engine's requirements for parallel build/execution. This means that the number of workspaces you see during a session will be fairly well in proportion with the global performance settings, 'Max number of processing threads' and 'Process pool size'. If you set these values lower, you should see less workspaces appear as the engine will be doing less work concurrently and consuming less resources. However, this will probably not work too well with your performance tuning goals, as turning these options down too far will likely create bigger performance issues than would otherwise be solved by introducing the RAM drive.
The duplication of workspaces is necessary because at any point in time, NCrunch can be running uninterruptable tests against any version of your source code. Let's just say you have a big integration test that takes 20 minutes to run and relies on a number of resource files inside your codebase... if you were to change several of these resource files while the test is already executing, it's important that the executing test can continue to work consistently and without consideration to the new changes.
NCrunch 1.37b (and below) has a known issue around read-only files, where if they exist in your solution, NCrunch will often fail to properly clean up workspaces that contain them. This only applies to final clean up (i.e. when NCrunch is disabled or the IDE is closed), but it can cause the number of workspaces to grow over time. This is particularly an issue if you're using any kind of VCS software that flags files as read-only during its normal operation.
