Flash Disk i/o Performance & Rebasing DLLs
SanDisk has a new 32 GB flash disk coming out that supposedly has 100x faster i/o than magnetic disks. For disk i/o constrained geoprocessing, sure seems like this could improve things.
Still, I wonder how much quicker Arcmap would load. I suspect a lot of the load time is not from disk i/o, but from “rebasing” dlls. I’ve noticed Arcmap startup time seems to increase more than linearly with the number of extension dlls being loaded.
This MSDN article describes the costs of rebasing.
Arcmap loads lots of dlls, written independently by different developers. It’s just not practical to collaborate on base addresses. The JIT Extension category improves things, but I still notice slower startup time when more extensions are installed – even if they are in the JIT category. If a toolbar is turned on that references an extension, then that extension will load at startup.
Have you ever noticed how Visual Studio loads slow the first time, but much faster for subsequent loads? This article sheds some light, quote:
“By the way, on the “faster load time” issue, I should mention that when an executable module is unloaded, Windows puts its pages on a “standby” list, a kind of cache from where the module’s pages can be retrieved very efficiently when it is loaded again. So if you load a DLL for a second time, and its pages are still in the standby list, it will load a lot quicker than the first time.”
Seems like ESRI Desktop apps could benefit from a standby list too.
But instead of assigning base addresses by hashing the dll name, it seems like we could rebase them using where they actually end up being loaded in memory, essentially persisting the standby list on disk.