arcobjects - Custom implementation of ArcGIS function

I would like to find out what it takes to create a custom implementation of an ArcGIS function. In particular, I would like to implement GeoAnalyst.ISurfaceOp2.Visibility() in order to get it to run faster. Right now, it is taking ~3 seconds per call to Visibility(). From my limited understanding, the bottleneck is the writing of temporary rasters to the file system. If this could be done in-memory, I suspect the processing time would decrease significantly. I am doing this in a .NET project, but solutions in any language are welcome.

Answer

This answer memorializes and expands on some of the discussion in the comments. A RAM disk emulates an external disk drive using some of the RAM in a computing system. It can read and write at speeds comparable to in-memory caching, minus a little overhead for the translation protocols to convert disk-oriented commands to memory-oriented commands. A RAM disk is created by running special operating system-level software, a "device driver." Open source and free RAM disks are available for many operating systems, including Windows.

Therefore, one way to speed up a bottleneck due to intermediate disk I/O is to set up a RAM disk (buying the additional RAM if necessary) and place the scratch folder there. (This is usually a software setting.)

Another option is to install a high-end DRAM solid state device (SSD), which essentially is a block of RAM in separate packaging with an electronic interface to act like a disk drive. It installs in a computing system in place of a disk drive and will behave exactly like another disk drive without any additional software, but will read and write almost as fast as memory accesses. These are relatively expensive, but likely only a small one is needed even for very large intermediate raster storage.

Before taking any of these steps, it is important to profile the process to ascertain where the bottleneck really is. (Windows has been delivered with increasingly powerful profiling and monitoring apps in recent years, available in Win 7 as the Task Manager/Resource Monitor pair, and of course many similar apps are available for other OSes too.) Many systems are automatically configured, or can be configured, to cache disk reads and writes in RAM for short periods. Caching works almost the same as a RAM disk, but is probably even faster: the software thinks it is writing intermediate files to disk, but the OS writes them temporarily to RAM first, not accessing the disk, in the hope that soon the same data will be read back and deleted, in which case a physical write will never be necessary. Profiling the physical disk operations while the bogged-down software is running will indicate whether or not disk I/O is the bottleneck.

Given the amount of computation needed for any full visibility calculation (in a naive algorithm, every cell has to be inspected for visibility once for each viewpoint), one should at least suspect that computing speed, not disk I/O, may be the problem here. If that is the case, RAM disks or SSDs will be a waste of time and money. Instead, effort should be directed at analyzing and improving the underlying algorithm.

Some discussion of whether RAM disk performance helps ArcGIS has appeared in another thread.