I have written an application that does a lot of geoprocessing using arcpy. Once started, the application itself runs at an acceptable speed, but it is very slow to boot. It can take 30 seconds or so to start up the GUI, so I'd like to find ways to make it start faster.

As far as I can tell, the main source of delay is when I set the dataframe as follows:

self.df = arcpy.mapping.ListDataFrames(self.mxd, "")[0]

Does anyone have any tips / tricks to make either the whole application or the ListDataFrames run quicker when the application is started?

I use ArcGIS 10.1, python 2.7 and tkinter for the GUI. Feel free to ask if I've forgotten to mention anything.


As requested, here is the (very!) stripped down version of the start my code:

import arcpy
import sys
from Tkinter import *
import ttk
import tkMessageBox
import tkFileDialog
import webbrowser
import time
import csv
import os
import textwrap

arcpy.env.workspace = r".\..\Append\temp.gdb"

Title = "Automated Map Generator"

class Application(Frame):
    def __init__(self, master=None):
        Frame.__init__(self, master, background = "white")


    def createWidgets(self, master):

        # setup map document
        self.mxd = arcpy.mapping.MapDocument(r".\autolim_mapping.mxd")
        arcpy.env.overwriteOutput = True
        self.df = arcpy.mapping.ListDataFrames(self.mxd, "")[0]

#[Lots of missing code here]

root = Tk()
app = Application(master=root)

How do I know what it's the ListDataFrames that takes so long? I put a whole heap of print statements through the startup code and noted how long they took to come out... I bet there are better ways to do this, but I'm pretty new to python.

EDIT 2: @dassouki - thanks! Here are the output times from after 'import time':

Start Class Application (Frame):  1.53200006485
Start def Create Widgets:         1.59400010109
Start  mapping.MapDocument:       1.6099998951
Start env.overwrite:              1.64100003242
Start mapping.ListDataFrames:     1.64100003242
Finish mapping.ListDataFrames:    12.2660000324
  • Is this intended to be a stand alone app? I'm sure you considered it, but it might be faster if you create a toolbox and make a script. It would have to be pretty advanced if you wanted to include data validation for user input on your GUI. That's all built it to a script. – Paul Jun 26 '13 at 22:19
  • Hi Paul - sadly yes, it needs to be a standalone app - the end users are not GIS people at all. – Callisto_NZ Jun 27 '13 at 4:16
  • 1
    Can you edit your post to include the code? If it's too long, you can dump it somewhere and just post the gist of it here. – Paul Jun 27 '13 at 4:23
  • 2
    Rather than post all the code can you just post enough to demonstrate your theory that LisDataFrames is the problem so that we can test to see if we can reproduce. – PolyGeo Jun 27 '13 at 7:50
  • 2
    When optimising you should never guess! That's what profilers are for. Show us the output and we will try to help. Also the code to at least see how it's implemented would be nice. – Michal Jun 27 '13 at 11:27

Based on your feedback, I would recommend you target your optimization on the MXD you're attempting to load.

MXD's can become bloated over time from storing geoprocessing and other information. Usually this isn't very noticeable, but if you're using the same MXD in production it could cause the slow down.

While your MXD doesn't seem that large, you may still have some luck optimizing how you are using the MXD, such as by modifying your script to create a blank MXD off of a template, deleting unnecessary layers in your MXD, or storing it locally.

I recommend you take a look at some of these questions regarding MXD file sizes and optimization:

What makes a MXD file size larger and how to decrease its size?

Python increasing the filesize of my .mxd

Problem: MXD file size increases significantly with subsequent saves

| improve this answer | |

I think the delay is caused by waiting for the license server. If you can, switch to a standalone license and compare the difference. I've noticed that at times, the checkout process can take some time.

Since we know that's not the issue, try installing 64 bit geoprocessing: http://blogs.esri.com/esri/arcgis/2012/11/12/python-scripting-with-64-bit-processing/

| improve this answer | |
  • Thankk @CLJ - I switched it over to a standalone licence and tried it. The time for doing mapping.ListDataFrames is still 12 seconds or so. I'd have thought that the time to check out a licence would have occurred during the 'import arcpy' step..? – Callisto_NZ Jun 28 '13 at 3:30
  • Bummer, yes I would think it would be in the import arcpy step. The only other thing I can think of to try is the ESRI 64 bit python install. – CLJ Jun 28 '13 at 3:36
  • 64bit BG will probably not make this faster. 64bit just gives you access to more RAM. Unless the MXDs have hundreds (maybe thousands of dataframes), I couldnt imagine how you'd need to leverage more RAM – KHibma Jun 28 '13 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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