•RivEX makes extensive use of a data structure called a dictionary.  These are far faster to access than reading and writing to a disk base attribute table of a river network.


•When you press the build button, RivEX builds the dictionaries and stores them on the hard disk in the river networks' workspace folder RivEX_Workspace\TopoCache. These files end with a "rtd" file extension. Technically they are serialized HashTables.


•If you process a large network ( > 20,000 polylines) then more time can be spent building the dictionaries than executing the algorithms!  Some of the dictionaries built are also queried as they are built, so as the dictionary gets bigger this process takes longer. 


•If your network has not been edited since the last dictionary build then RivEX will simply re-establish a link to these stored dictionaries which means the build process is instant. This is a significant improvement over the previous version of RivEX which had to rebuild the dictionaries every time RivEX was run.


•As a benchmark for very large river networks, RivEX was tested using a network of just under 420,000 polylines and it took about 11 minutes to build the dictionaries and write then to the TopoCache folder. This was on a VISTA 32bit Core 2 Quad machine with 4GB of memory. Your processing time will vary depending upon your system specifications and the rivers' network topology.


•You can improve the general performance of ArcMap by building indices for your data.  If your data is a Shapefile, ensure a spatial index has been built.  Once the node fields have been created, build attribute indices for improved read access. Click here to see how an index is built. 


•The network topology drives the performance of RivEX. If your network is lots of catchments draining to the sea, an island situation such as the UK, then this is the idea situation for RivEX. Anyone catchment is small enough to traverse without causing memory issues. Thus your dataset could have a million polylines and RivEX will process it without problems. If your network is a large multi-threaded network draining to a single mouth at the sea then this is the worst case scenario for RivEX! It means the algorithms that traverse the network can end up in a very deep recursion which may exceed the limitations of the operating system causing a stack overflow error. Two examples of  an ideal and worst case scenarios are shown below and discussed.


A network with many catchments, this network works best with RivEX

A highly braided network draining to a single mouth, this is a network that RivEX will process slowly.

Iceland is a good example of a network dataset that will process efficiently in RivEX. It has many small catchments. The way RivEX extracts and stores the topological information means such networks are ideal and will process extremely fast. No one catchment is large enough to create a deep recursive traverse, yet the network could have a million polylines!

This is a small part of a huge network dataset for the River Murray in Australia. It is composed of 300,000 polylines. RivEX could easily process a network with this number of polylines if it had a configuration similar to Iceland (many smaller catchments). But in the image above the entire connected network drains to a single mouth (black point). It is also highly braided. Whilst RivEX can process this dataset it's topological configuration is not well suited for RivEX and how it traverses the logical network. In this case RivEX will process the network slowly and may even fail as the recursion that some algorithms use exceed the limitations of the operating system.