¿Geodatabase de Archivos, el rendimiento se degrada, como se llena?

Question

Estoy teniendo un problema de pérdida de memoria. Al investigar esto más, parece que el archivo de base de la geodatabase escribo en un bucle, es de crecimiento muy grande, y a medida que crece, se degrada significativamente el rendimiento de los scripts estoy corriendo.

Alguna idea de cómo optimizar la configuración de la fgdb? O cómo la velocidad de todo esto? Yo no soy 'de la escritura in_memory', estoy usando aggregatePoints para crear una temp featureclass (que voy a borrar), y me búfer de este FC, que me mantenga.

Sin embargo, parece más lento y más lento y más lento...

def createGeom1(geom, scratchDB):
    filetime = (str(time.time())).split(".")
    outfile = "fc" + filetime[0] + filetime[1]
    outpath = scratchDB + "tmp1.gdb/Polygon/"
    outFeatureAggClass = outpath+outfile + "_Agg"
    arcpy.AggregatePoints_cartography(geom, outFeatureAggClass, "124000 meters")

geom es una colección de Puntos, cero cero área local (gdb estoy usando).

Sólo un bucle a través de una lista de archivos, puedo llamar a un procedimiento que crea alist de geoms (y no se degrade) y, a continuación, llamar a este. Haciendo esto, va a ver esta función, createGeom, degradar significativamente, y el anterior, no un poco.

Answer 1

Sé una respuesta ha sido aceptado ya, pero pensé que me gustaría añadir mi experiencia y algo de código que uso para conseguir alrededor de él. Tengo un proyecto que genera un gran volumen de datos intermedios. El tamaño es pequeño, pero el número de características/rásteres es significativo. Después de tener a mi programa de referencia donde la pérdida de rendimiento que estaba ocurriendo, estaba claro que estaba sucediendo en el FGDB escribe. En el inicio del programa, un FGDB escribir tomaría ~2 segundos. Después de la adición de aproximadamente 100-150 características, se necesitarían alrededor de 6 segundos, y aumento de aproximadamente de forma lineal a partir de ahí.

Lo resuelto por la creación de un simple gdb de la clase que controla el número de cuenta y crea un nuevo gdb para ese propósito, si hemos alcanzado el umbral. NOTA que se requiere un poco de adaptación, pues se necesita un nombre de variable en otro módulo como un parámetro y establece que el valor de la variable a la ruta de acceso a la gdb. En este caso, el módulo es "config", como se ve en el método switch() a continuación. Si usted correcto que a su propio módulo (o desconecte el conjunto de un nombre en el módulo actual), esto se puede adaptar. También genera nombres mediante la división de la FGDB nombre de la variable de entrada, por lo que necesitará semillas que la primera. De lo contrario, usted puede ajustar el código de inicialización se comportan de manera diferente.

db_size_threshold = 150

class gdb:
    def __init__(self,tconfig=None):
        self.name = None
        self.config_var = tconfig
        self.parent_folder = None
        self.db_count = 1
        self.features_count = 0

        name_parts = os.path.split(getattr(config,self.config_var))
        self.name = os.path.splitext(name_parts[1])[0]
        self.parent_folder = name_parts[0]

        self.switch() # make a new db to start

    def check(self):
        '''checks if we've hit the threshold - if not, increment its count'''

        if self.features_count > db_size_threshold:
            self.switch()
        else:
            self.features_count += 1

    def switch(self):
        '''creates a new gdb for this object''' 

        new_name = self.next_db()

        arcpy.CreateFileGDB_management(self.parent_folder,"%s_%s.gdb" % (self.name,self.db_count))
        self.features_count = 0

        setattr(config,self.config_var,new_name)

    def next_db(self):
        '''returns the name of the next db after checking for existence - this could possibly use arcpy.CreateUniqueName instead'''
        new_name = os.path.join(self.parent_folder,"%s_%s.gdb" % (self.name,self.db_count))
        while arcpy.Exists(new_name):
            self.db_count += 1
            new_name = os.path.join(self.parent_folder,"%s_%s.gdb" % (self.name,self.db_count))

        return new_name

He encontrado 150 a ser una buena solución de compromiso entre la complejidad y el rendimiento para mi proyecto. Escribir veces tienden a fluctuar entre 3 y 7 segundos con el umbral. Conjunto de db_size_threshold a todo lo que la balanza usted está mirando a la huelga en su propio hardware.

Answer 2

Dependiendo del tamaño de su geodatabase de archivos, usted podría ser capaz de utilizar un disco RAM (por ejemplo, ImDisk: http://www.ltr-data.se/opencode.html/#ImDisk ). Podría acelerar las cosas si los discos duros son más lentos.

He aquí una pregunta (la mía) acerca de los Discos RAM: ¿Alguien ha experimentado notables incrementos de rendimiento en ArcGIS Desktop utilizando un Disco RAM?

El Disco RAM opción es fruta madura. Y por desgracia, creo que no se puede vincular a whuber: comentario sobre esa pregunta, pero creo que resalta en donde la mayoría de las mejoras de rendimiento que se puede hacer (así que tal vez debería publicar su código en cuestión).

whuber: Incluso una de gama alta (ordinario) de la unidad de disco puede hacer una apreciable diferencia. Sin embargo, por mucho, el más notable mejora en tiempo de ejecución de los SIG de los procesos se realiza mediante la mejora del algoritmo. En muchos, muchos casos, si su cálculo se toma bastante más tiempo que el tiempo necesario para leer todas las entradas y escribir todas las salidas, las posibilidades se está utilizando un algoritmo ineficaz.

Answer 3

Hay una fuga de memoria en ArcGIS 10, que se fija en el SP3 al parecer.

También, decidí eliminar el 'in_memory de datos y compactar la base de datos en cada bucle. que en realidad sped de la aplicación. Entonces, cuando ejecuto el script de nuevo, voy a borrar el fgdb y volver a crearla. es sped todo hasta en un 30%. Sin embargo, una vez que la pérdida de memoria se ha fijado, esperamos mucho mejores ganancias en el rendimiento. Arcpy es un cerdo en bucles...

Answer 4

Retirar el elemento #4 de mi respuesta para esta pregunta relacionada con el Rendimiento de ArcGISScripting y grandes conjuntos de datos espaciales apuesto a que eres de carga dentro de un EditSession y que usted no está utilizando el reciclaje de los cursores :)

Actualización basada en los comentarios:

Aunque ArcPy y ArcObjects son sintácticamente diferentes, en esencia es la misma. Se preguntó si el rendimiento de FileGDB se degrada a medida que se llena. La respuesta es no , que no. Lo que se degrada es cuando los cursores usted está utilizando ya sea explícita (yo.e por que declara a sí mismo) o implícitamente (mediante el uso de una lata de arcpy función que crea) no se libera correctamente. Hay un precio para el uso de la conserva de funciones - un intercambio de simplicitly para el control de recursos (que apenas tiene cualquiera). Esto no es inherente a FileGDB, pero a ArcGIS arquitectura como un todo. El momento de elegir el uso de ArcPy, que están haciendo de la declaración de "prefiero trade-off de la complejidad de la utilización de un nivel inferior de la API para el rendimiento". Cuanto más se asciende, más que el comercio. ArcPy es mucho más bonita en la parte superior de todo... una función y listo! Sin embargo, que el hilo todavía iba a la ArcObjects proceso de inicialización, y el asociado del área de trabajo de la fábrica de la asignación, y el fichero de asociados abrir identificador para cada espacio de trabajo temporal (de un total de gdb!) y hasta que la memoria interna de liberar a las rutinas de patadas en el (en .net se puede llamar explícitamente a la gargabe colector y en C++ es inmediata, no estoy seguro acerca de la Python-Com, modelo de memoria sinceramente) que tenga estos gdbs y recursos de estancia de residente. Así que usted probablemente tiene varios dbs, y el fc maneja en la memoria cada vez que el bucle. Ese es el precio de ArcPy y es hasta usted para decidir si vale la pena.