Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I configured a RAM disk on a Virtual PC running ArcGIS Desktop 10 and set my HKCU\Software\ESRI\Output\TempPath to a directory on the RAM disk. It’s hard to perceive any sort improvement with that sort of configuration and I’m curious to know if anyone else has done this on a non-virtual computer and what the results were.

Anecdotal answers are fine.

Also, putting the cache path on a ram disk is probably not a good idea, but is anyone doing this anyway? (HKCU\Software\ESRI\Desktop10.0\Settings\Cache Path)

share|improve this question

6 Answers 6

up vote 5 down vote accepted

One of my former workmates set up a long-running GIS computation process such that it saved intermediate results on a RAM disk. Both he and his boss claimed that there was a very significant speed-up of the computation process, and computation time was quite critical in their project.

I personally couldn't quite figure out why the RAM disk was needed at all. If they had just kept the intermediate results in memory (as regular, non-persisted objects) instead of "writing" them to a (RAM) disk, that would have made absolutely no difference in my opinion.

But I suppose there could be potential cases where the API would force you to persist objects before you can process them further (e.g. because a particular computation expects a filename as its input). In such cases, I imagine that a RAM disk (being a workaround to prevent real harddisk I/O) might help.

share|improve this answer

I've played a bit with RAM disks for a GIS, with mixed results. Its good to think about what you're trying to achieve, and how RAM might help: often, GIS analysis do sequential I/O operations, which aren't significantly faster in memory. Plus, the OS is already caching frequently accessed data from disk, which means that only the initial seek is costly.

As a general recommendation, I'd say using two disks (one for input, the other for output) shows good returns, and switching to Flash are much better options than trying to squeeze performance out of reconfiguration of your existing hardware, except in edge cases.

share|improve this answer

Instead of creating a RAM disk, how about using a "disk" that's made out of RAM? Also known as a Solid State Drive.

We bought some OCZ Revo X2 Drives a couple of months ago and are very happy with them so far. I don't have specific statistics to share but the interactive performance when working with local data is definitely noticeable. The best site by far I've located for reading up on SSDs and related technology is StorageSearch.com which has been publishing buyer's guides since 1998 and as near as I can tell does a better than average job of staying independent from the vendors.

share|improve this answer
2  
+1 Even a high-end (ordinary) disk drive can make an appreciable difference. However, by far the most dramatic improvement in long-running GIS processes is made by improving the algorithm. In many, many cases, if your computation is taking noticeably longer than the time required to read all inputs and write all outputs, chances are you are using an inefficient algorithm. –  whuber Apr 20 '11 at 18:36
    
A solid state drive is not made of the same kind of RAM as your computer memory. While much faster than a spinning disk, it is also much slower than the RAM on your motherboard. Of course, you can install an SSD with hundreds of gigabytes of storage ; few motherboards will support that much RAM, even if you could afford it (at least 10X the SSD). Just one more tradeoff point in the space/speed/cost space. –  Llaves Apr 23 at 3:27

That is actually one of the recommendations you will see from ESRI when it comes to high-speed or large quantity Geocoding. Storing your locators on a RAM-Disk makes them lightning fast since there is no disk-io contention issues. You can even write your output to a RAM-Disk for increased performance, then just at the end of the process move the data to a static drive.

I have been looking at this heavily for a while; and just have not had enough time to put it into normal practice.

share|improve this answer
    
can you provide a citation? that would be helpful –  matt wilkie Apr 21 '11 at 19:08
    
There is my own experience; plus there is a ESRI whitepaper on Geocoding performance tuning... There is this one; esri.com/library/whitepapers/pdfs/arcgis-server-in-practice.pdf but it doesn't have that section; I guess they may have depricated that doc. I have done a few tests with it; but Windows Vista doesn't do the RAM disk well. I need to get back and try it again now ther might be better drivers to support it. –  D.E.Wright Apr 24 '11 at 0:55

I implemented a RAM Disk solution in the hopes of speeding up calls to GeoAnalyst.ISurfaceOp2.Visibility(). This was a .NET project on 64-bit Windows 7. I used IMDisk for the RAM disk and it did not make any noticeable speed improvements. Further details can be found in this question

share|improve this answer

I've had great performance increases - far beyond what I get from using my SSD, by using the free (up to 4GB) software: DataRAM Ramdisk. Of course this only applies to operations where there is disk IO.

share|improve this answer
    
I had an SSD on my company laptop and I miss it. Everything was faster. I 'upgraded' to workstation 8-core, 8GB, 64bit from a 4-core, 4GB, 32bit machine (both manufactured in 2011). Just couldn't take all my data with me. So bye-bye SSD. :( I'm going to look into the DataRAM Ramdisk. Thanks for sharing. –  Kstoney Mar 6 '12 at 22:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.