[crappy software filter] How can I speed up ESRI ArcMap?
February 7, 2011 2:21 PM   Subscribe

[crappy software filter] How can I speed up ESRI ArcMap?

I am forced to use ArcMap nearly every day at work. Problem is, it's one of the most horribly slow programs ever made. Surely, SURELY, there is some way to speed it up? Otherwise I can't imagine how anybody ever gets anything done using it.

How the heck can I speed up this piece of garbage?

For instance, with NO layers turned on, it takes like 20 seconds just to copy and paste a line that I drew in the Layout View. Then, to delete that line takes 10 seconds. When I do other things, like use the "Clip" feature in the Toolbox, and select the input file for the clip it sits there for about 30 seconds before I can even proceed with the next step (what IS it doing???). Refreshing even the most basic things in the interface takes FOREVER. I mean damn, my computer is pretty new and most other applications work fine.

At this point I'm just getting tired of things in ArcMap taking 100 times longer to do compared to other programs. Things which, I feel, should be instant (like selecting a menu or tool option).

I'm running ArcMap 9.3 under Windows XP Pro on a 3.4 Ghz Pentium D (Core 2 Duo I think?) with 2 GB RAM. I looked at the Task Manager and it seems like I always have at least 500 MB of free RAM so I don't think RAM is the issue. Although, honestly, this computer seems a LOT slower than my 2.5 Ghz Macbook Pro but that's probably just Windows XP.

And no I can't upgrade ArcMap, or Windows, or the computer hardware. And yes, it's slow for everyone else in the office, too. Unlike them, I actually want to get work done. I feel like if this damn thing had a responsive interface I could get 10 maps a day done, instead of 1 or 2... and then be able to do the part of my job that I actually like.

posted by buckaroo_benzai to Computers & Internet (24 answers total) 6 users marked this as a favorite
A 3.4 Ghz Pentium D is essentially two Pentium 4s mounted on the same die. It's three generations behind the chip in your MBP, and it's significantly less efficient at the same speed, so ignore the 3.4 vs. 2.5 comparison.
posted by Oktober at 2:26 PM on February 7, 2011

Response by poster: Ok, you're right, I looked it up and the Pentium D apparently last shipped in 2008 so the computer isn't as new as I thought. But still, at 3.4 Ghz, it should not take forever just to change basic interface elements. Also, for what it's worth, ArcMap 9.3 was also released in 2008. So yeah, theoretically this system should work well??? It's not like I'm trying to run new software on old hardware. I digress back to my original statement of how does anyone get work done in ArcMap if it's so slow?
posted by buckaroo_benzai at 2:34 PM on February 7, 2011

ArcMap is slow but that is really slow. Are you working off the server or your hard drive? Do you have a bunch of huge layers (like possibly a topo of the entire country) in your workspace? Some time spent cutting big layers down and moving them to your local drive will be well spent.
posted by fshgrl at 2:34 PM on February 7, 2011 [1 favorite]

Do you have your layer files on a network drive?

ArcMap 9.3 is painfully slow when using files from a network. I put most of my layer and raster files on my hard drive and it is significantly faster. However, it is still slow and I frequently use 3.2 to get work done. I love my job, but ESRI software is so aggravating.
posted by Beardsley Klamm at 2:35 PM on February 7, 2011

Response by poster: Everything is on a network drive, and the layers are all clipped to the county that I manage. But even with layers turned off it's slow (although it does help a lot when it doesn't have to redraw aerial imagery all the time). I'm so tired of staring at the hourglass... or wondering "Did I actually click that? Or is it just not responding yet?"

I can't really copy the layers to my local disk because then the layer targets wouldn't work when someone else accessed the file. It has to be on the common network drive.

Is there no way to force ArcMap to cache the data locally while the file is being worked on? (I kind of assume that a well-designed program would do that automatically...) The layer files aren't that big.
posted by buckaroo_benzai at 2:43 PM on February 7, 2011

Do you have a dedicated GIS server at least?
posted by fshgrl at 2:48 PM on February 7, 2011

Response by poster: No, it's just a shared network drive with the .shp and other associated files on it, and the drive is only for GIS data (not general file storage). It's the federal government so getting them to change how it's currently done is impossible. I'm really hoping there are some tips and tricks I can use to live (productively) with this pile of crap I've been handed. I don't have admin access to the machine, either.
posted by buckaroo_benzai at 3:01 PM on February 7, 2011

If you were to copy the files into a local drive, that shouldn't affect accessibility for another user. You're creating separate files by doing this. However, if there are additional people that need to work with and edit the same file, that would be a problem. In my scenario, I am the only person using and editing my layer files, but if anybody needs access I just copy the updated file back into the network. I'm pretty sure files can be synchronized across multiple drives, but I don't know if synchronizing a network file with a local drive file would speed things up since ArcMap would still be reading the network file.

You should at least figure out if this is the issue. Open ArcCatalog and copy and past the files into a folder in your hard drive and start up a new mxd project using those files.
posted by Beardsley Klamm at 3:03 PM on February 7, 2011

Response by poster: I think the problem is that multiple people need to be able to access the same mxd files and the same geodata. Plus the geodata occasionally gets updated remotely on the network drive by our geodata admin staff (to clarify, the network drive is in office over the LAN, so we access it locally).

So yeah, it's not possible to copy the layer files to the C: drive because 1) everyone in the office would have to do it, otherwise the mxd file would have broken links and 2) that would never happen because eventually all the files on our C: drives would be out of date.

The LAN is 100Mbps and the drives are 10,000 rpm Ultra SCSI. I don't see how the network could be the bottleneck, especially when ArcMap is only reading/loading shape files that are maybe 1-3 megabytes each (sometimes less). On a 100mbit network that should take a fraction of a second to transfer.
posted by buckaroo_benzai at 3:14 PM on February 7, 2011

Response by poster: Unless I'm missing something and there's a way to force ArcMap to copy/cache the files locally when it needs them? (with the layers still pointing to the network drive)
posted by buckaroo_benzai at 3:15 PM on February 7, 2011

I think there is but you need a degree in ESRI-ology. Why don't you ask the miss to re-title your post something like " GIS Experts Please Help!!" so the folks who know this program well see it?
posted by fshgrl at 3:21 PM on February 7, 2011

I cant answer your last question about caching files but I can say that no-one, myself included, doing GIS in our company does any substantial work off of our servers. It all gets copied to our local machines and then gets archived on the server when its done. It's just too damn slow otherwise.
posted by elendil71 at 3:28 PM on February 7, 2011

I'm thinking you'd want the file source to point to your local drive, and copy to the network, but I don't know if this is possible. I'm personally hoping this issue was addressed in their latest release (ArcGIS 10), but I'm not counting on it.
posted by Beardsley Klamm at 3:40 PM on February 7, 2011

I feel your pain. I second that getting the layers off the network drive is a good fix. As long as you always use ArcCatalog to move them, and copy the potentially new ones off the network drie before you start work each day and save your newly completed work to the network drive each night you should be okay.

One thing no one else has mentioned yet that might be work trying. Another thing that can happen if you run ArcGIS all the time is that your entire hard drive becomes a giant fragmented mess. When I was working mostly in ArcGIS on an older machine I had to defragment once a week to keep the computer functional.
posted by hydropsyche at 3:49 PM on February 7, 2011

Do you always use the same MXD? If so, I would open a clean MXD and drag the layers you use into it. Sometimes an old map document can bog down even if you delete old layers.
posted by Duffington at 4:14 PM on February 7, 2011

especially when ArcMap is only reading/loading shape files that are maybe 1-3 megabytes each (sometimes less)

Are you sure? I haven't had the pleasure of dealing with ArcMap in a bit, but I've been optimizing a (non-spatial) database and if not done right, a query can drag a whole linked table over the network, even stuff you don't need. I believe what you want is geodatabase replication. Best of both worlds, you get to keep your network copies but synch your local files to it.

Please add the GIS tag; there are plenty of GIS users around mefi.
posted by desjardins at 4:31 PM on February 7, 2011

What service pack are you on with 9.3? Their service packs are notoriously hit or miss.

If your work environment requires everyone to share shp files out on the network, there is nothing you can do, copying them local might cause issues down the road.

Your Pentium-D doesn't matter - ESRI software is still all single-threaded which means they cant take advantage of that dual or quad core CPU. You would want the fastest (in Ghz and operations per clock cycle) CPU, not the most parallel. The new Intel Core-series CPUs are 1.5x as fast as a P4-D for each GHz, so 3.4Ghz Pentium D is really like a 2.1Ghz Core i5.

And yes, ESRI software is notoriously awful. Its so bad their software developers should be fired. Out of a cannon. Into the sun.
posted by SirOmega at 4:53 PM on February 7, 2011 [2 favorites]

you mentioned that the layers are clipped to the country that you manage? I know when I used to work on state maps, I'd occasionally copy just the data for the state I was working on out of the entire map of the united states - if I would have been just showing a particular state out of the entire map of the US, it would have taken forever to load... so if your definition of 'clipped' just means 'hidden', that could explain your long load times... though I'm not sure if making a copy of your country's data to a new layer is really an option for you if you're sharing source layer data with other people.

It's been a couple years since I've touched the stuff... but there might well be a setting for local caching of network resources (I remember there being an entire menu and submenu of settings for just about everything you could conceive there being a setting for...)
You might have to check out the New forum and Old Forum on ESRI's web site - it'll give you something to do while your map is loading.
posted by itheearl at 8:02 PM on February 7, 2011

I've experienced major differences from computer to computer accessing the same networked MXDs. One was like you said while others worked fine so... I know you can't upgrade your hardware now, but if a machine in your office is faster, it might be worth scheming about how to inherit that one.

All this talk of local caching of shapefiles seems a bit off-base if you're having this problem with no layers turned on. Could you make a local copy of the MXD (change your data sources to "absolute" before copying). But my last Arc experience was 9.1 so I defer if others have a better idea.
posted by salvia at 8:27 PM on February 7, 2011

Response by poster: I'm clipping to the county level (not countRy). And it does create much smaller files compared to the state level data.

Clearly I need to take a look at ArcCatalog as well. I haven't ever used it since we received no training on what it's for or how to use it. Bleh.

I will address the other comments tomorrow while I'm waiting for map to load. Right now I need a beer.
posted by buckaroo_benzai at 8:32 PM on February 7, 2011

Response by poster: Okay, so I have been trying a few things. I turned on the "Map Cache" toolbar and clicked to create a map cache. I tried it with some of the WMS layers I have, as well as with shape files. It doesn't seem to actually speed anything up (zooming and panning are the same before and after I build the cache). ESRI's online help doesn't really tell me when a Map Cache is useful. What the heck is this tool for?

I also found that turning on the Labeling toolbar gives me an option to "Lock Labels". This speeds up some re-draws where labels are involved. As well as the ability to hit the Escape key to cancel some operations.

Any other useful tips and tricks to speed it up?

Also what's the deal with "geodatabases"? I read that you can speed it up with those, but I don't know what they are, or how to create them, or even if they are appropriate for my workflow (given that I have to use the shapefiles on the network drive AND share my mxd files with other users). It may be an extra step that just won't work for me.

I am trying to see if there is any way I can copy the shapefiles to my C: drive, while still maintaining references in the TOC that point to the network drive (for the reasons stated in one of my previous replies). I'm thinking some sort of script could do this, but I'm not a programmer, so I'm at a dead end. I'm probably dreaming, but it'd be great if I could specify two locations for each layer: one on the C: drive, and then if that doesn't exist, check the F: drive (the network). That way I could copy the files to my C: drive, but other users (who wouldn't do it because it'd be "too complicated") would still be able to use the same mxd when it reverted back to the F: drive. Like I said, I'm probably dreaming.

Any ideas? I probably sound like an idiot because I've only been using ArcMap for a few months and have pretty much had to figure it out on my own. I really, really want to figure out how to squeeze every bit of efficiency out of it so I can get on with my day...
posted by buckaroo_benzai at 10:53 AM on February 8, 2011

> I turned on the "Map Cache" toolbar and clicked to create a map cache. I tried it
> with some of the WMS layers I have, as well as with shape files.

The help file says: "The map cache only stores features in geodatabases and ArcIMS feature services, so no data from rasters, coverages, shapefiles, or other types of services is cached." A case of Sounds Cool Not Useful.

> Also what's the deal with "geodatabases"?

Shapefile limitations (file size, column header length, etc) forced ESRI to create the personal geodatabase (wrapped in an Access MDB) and file geodatabase formats. Besides fixing the size/header limitations GDBs allow for topology rules like "must not have gaps" or "must not intersect". For example a soil layer might have the former rule so voids aren't created.

I generally see GDBs from agencies with data sources that make use of topology rules, otherwise shapefiles are still the rule.

> I'm probably dreaming, but it'd be great if I could specify two locations for each layer

This might wake you up: give the "Set Data Source(s)" tool in ArcCatalog a whirl. It modifies the mapfile and rewrites the path for one/many/all layers in a single click, right-click any MXD to launch the tool.

> Any other useful tips and tricks to speed it up?

Your slowness is out of the ordinary even for the notoriously slow ArcMap. Are you on maintenance? ESRI tech support could have you capture a session with something like ProcMon to determine what's blocking progress of things like dialog boxes.
posted by llin at 11:42 AM on February 8, 2011

Any other useful tips and tricks to speed it up?

If you're just doing borders and legends and whatnot in layout view, you can pause redrawing altogether.
posted by salvia at 11:34 PM on February 8, 2011

(I think you can still do legends with redrawing paused. You can definitely draw that line you mentioned earlier.)
posted by salvia at 11:35 PM on February 8, 2011

« Older Wait, maybe I SHOULDN'T blog about this   |   Did we do that? Newer »
This thread is closed to new comments.