programacion optimizacion intermedio compilacion codigo delphi optimization compiler-construction

delphi - compilacion - optimizacion de codigo intermedio



Delphi: ¿Cómo organizar el código fuente para aumentar el rendimiento del compilador? (17)

Estoy trabajando en un gran proyecto delphi 6 con bastantes dependencias. Lleva varios minutos compilar todo el proyecto. La recompilación después de unos pocos cambios a veces es mucho más larga para que sea más rápido terminar Delphi, borrar todos los archivos dcu y volver a compilar todo.

¿Alguien sabe una forma de identificar, qué hace que el compilador sea más lento y lento? ¿Algún consejo sobre cómo organizar el código para mejorar el rendimiento del compilador?

Ya he intentado seguir cosas:

  • Incluya explícitamente la mayoría de las unidades en el dpr en lugar de confiar en la ruta de búsqueda: no mejoró nada.
  • Utilice el compilador de línea de comandos dcc32: no es más rápido.
  • Intente ver qué hace el compilador (usando ProcessExplorer desde SysInternals): aparentemente ejecuta la mayor parte del tiempo una función llamada ''KibitzGetOverloads''. Pero no puedo hacer nada con esta información ...

EDITAR, Resumen de las respuestas hasta ahora:

La respuesta que mejor funcionó en mi caso:

  • La función "Limpiar referencias de unidades no utilizadas" de cnpack . Limpió casi automáticamente más de 1000 referencias, haciendo una compilación "fría" aproximadamente dos veces más rápida. (compilación "fría" = borrar todos los archivos dcu antes de compilar). Obtiene la lista de referencia del compilador. Entonces, si tiene un {$ IFDEF}, verifique que todas sus configuraciones aún se compilan.

Lo siguiente que me gustaría probar es:

  • Refactorizar las referencias de la unidad manualmente (eventualmente usando una clase abstracta) pero es mucho más trabajo, ya que primero necesito identificar dónde están los problemas. Algunas herramientas que pueden ayudar:
    • GExperts agrega un navegador de dependencias de proyecto al delphi IDE (pero desafortunadamente no puede mostrar el tamaño de cada rama)
    • Delphi Unit Dependency Viewer V1.0 hace casi lo mismo pero sin Delphi. Puede calcular algunas estadísticas simples (¿Qué unidades es la más referenciada, ...?)
    • Icarus que se hace referencia en un enlace en una de las respuestas.

Cosas que no cambiaron nada en mi caso:

  • Poner todos los archivos de mi programa y todos los componentes en una carpeta sin subcarpetas.
  • Desfragmentando el disco (lo intenté con un ramdisk)
  • Usando un ramdisk para el código fuente y las carpetas de salida.
  • Desactivando el antivirus en vivo
  • Enumerar todas las unidades en el archivo dpr en lugar de confiar en la ruta de búsqueda.
  • Usando el compilador de línea de comandos dcc32 o ecc32.

Cosas que no se aplicaron a mi caso:

  • Evitando tener dependencias en recursos compartidos de red.
  • Usando DelphiSpeedUp , porque ya lo tenía.
  • Usando una sola carpeta para todos los dcu (siempre lo hago)

Cosas que no probé:

  • Actualizando a otra versión de Delphi.
  • Usando dcc32speed.exe
  • Usando una unidad de estado sólido (no lo probé, pero probé con un ramdisk donde puse todo el código fuente. Pero tal vez debería haber instalado Delphi también en el ramdisk)
  1. ¿Ha establecido una sola carpeta para obtener las DCU? Si no, se dispersarán por todas partes.
  2. Coloque todas las unidades y sus unidades llamadas implícitamente (excepto los componentes instalados de la ruta de la Biblioteca) en dpr. Para asegurarse de que no se le escapó algo, vacíe su ruta de búsqueda, todavía debe compilarse.
  3. Después de reducir la ruta de búsqueda, puede intentar reducir la ruta de la biblioteca instalando los componentes en menos carpetas.

Algunas cosas que podrían ralentizar el compilador

  • Unidades redundantes en tu cláusula de uses . Consulte esta pregunta para obtener un enlace a CnPack .
  • No agrega unidades explícitamente a su archivo de proyecto. Ya parece haber cubierto eso.
  • Cambió la configuración del compilador, más notablemente include TDD32 info .

Intenta deshacerte de las unidades no utilizadas en tu cláusula de uso y ve si hace una diferencia.

Aunque solo en parte es relevante para su pregunta exacta, escuché que el uso de un disco de estado sólido aumenta enormemente el tiempo de compilación con Delphi - Nick Hodges dijo esto mismo en el Podcast de Delphi hace un par de semanas. Brian

Como no acumulé 50 puntos de reputación, no puedo responder a mi publicación de BALLS OUT. Entonces, tengo que comenzar una nueva línea de pedido aquí. Compré la máquina para trabajar en archivos de Photoshop muy grandes, y también hago muchos modelos 3D en Inventor y 3DStudio MAX. Es por eso que compré la nueva máquina. PERO ... Definitivamente recibí un impulso tremendo en mi uso de Delphi debido a eso. Mi sueldo cuesta mucho más que los 2K adicionales que gasté en la nueva máquina, en comparación con la compra de algunos Dell básicos (lo cual puede estar bien para Delphi). Entonces cualquier IMPRESIÓN que pueda recibir es una BONIFICACIÓN. Si haces este trabajo todo el día, todos los días como yo lo hago, cualquier latencia que experimentes comienza a convertirse en un verdadero problema. Lo que hizo por mí con el uso de Photoshop, productos de Autodesk y DELPHI. Entonces lo diré nuevamente, una nueva máquina BALLS OUT, MEJORARÁ su rendimiento. El tipo pregunta qué puede hacer para mejorar el rendimiento de compilación. Entonces, di mi opinión.

PD Ponga a Delphi y su proyecto en una Unidad de estado sólido, y verá una GRAN mejora en la velocidad.

Compruebe si hay rutas en las rutas de búsqueda que no están en su máquina local.

es decir, no enlace a archivos binarios en recursos compartidos de red, y verifique que la ruta de búsqueda no esté controlando ningún recurso compartido de red.

El compilador solo compilará las unidades que han cambiado. Si ha cambiado el código en la sección de interfaz, todas las unidades que dependen de la unidad modificada se compilan. Si solo se modifica el código en la sección de implementación, la compilación solo incluirá esa unidad pero, presumiblemente, vinculará todos los módulos. Implica un buen diseño de interfaces por adelantado, pero si reestructura el código para restringir los cambios en la implementación, los tiempos de compilación podrían reducirse. No tengo idea de cuánto. Este hecho se menciona en los archivos de ayuda de Delphi en Referencias de unidades múltiples e indirectas en Delphi 7 "Using Delphi".

Intente instalar un disco RAM y configure su ruta de salida dcu para apuntar allí. Esto más que redujo a la mitad mi tiempo de compilación con Delphi 2007 en la parte superior de DelphiSpeedUp.

Lo que hago es siempre asegurarme de tener muy pocos directorios en la ruta de la biblioteca, y la mayoría de los componentes y el código estático. También me aseguro de que NO haya ningún código fuente disponible en la ruta de la biblioteca, solo .dcu / .res, etc. Solo browsepath tiene el código fuente y las circunstancias especiales se manejan a través de searchpath para el proyecto.

Solo limite lo que compila en cualquier situación.

No he visto que el compilador sea más lento con el tiempo, pero ha pasado mucho tiempo desde que usamos Delphi 6.

  1. En general, en la comunidad Delphi parece haberse acordado que, si no desea actualizarse a lo último y mejor (Delphi 2007 o 2009), entonces Delphi 7 es el mejor / más rápido / más estable. Puede considerar actualizar.
  2. KibitzGetOverloads suena como algo del compilador de kibitz: el compilador de "fondo" que te proporciona completar el código, destacar el error de fondo, información sobre herramientas de código, etc. Parece que sería mejor que verificaras la pila de llamadas del compilador de la línea de comandos. no el IDE; obtendrías algo más útil.
  3. Nunca he encontrado que las compilaciones sean más rápidas después de eliminar las DCU. Las DCU están ahí para hacer que la construcción sea incremental, por lo tanto, más rápida. Si ve compilaciones más rápidas después de eliminar todas las DCU, verifique su hardware. ¿Has desfragmentado tu disco duro últimamente? ¿Cuánto espacio libre tienes en el disco?

Podrías probar con DelphiSpeedUp y ver si hace la diferencia. No acelerará la compilación de línea de comandos, pero afirma tener algunas aceleraciones para la compilación de IDE.

Tuve el mismo problema y puedo encontrar dos (2) razones por las cuales me afectaron.

  1. Referencias circulares El caballero que dijo que uno era correcto. Tendría ciertos proyectos GRANDES que compilarían rápido, y proyectos PEQUEÑOS que se compilaron lentamente. No pude resolverlo hasta que reestructuré el código y luego obtuve las velocidades de compilación más rápidas. Montones de unidades pequeñas Es fácil construir unidades monolíticas. Pero, hay muchas penalidades de eso.

  2. Lo he escuchado mil veces, desarrollar en una máquina lenta como la que podrían estar usando sus usuarios. Oye, eso es para el departamento de pruebas. No puedo perder el tiempo con la compilación, las velocidades de carga de Delphi, los paquetes, etc. Salí y compré una computadora "GAMERS" (WOW) con las unidades de estado sólido (como se mencionó anteriormente), 12GB de RAM, el chip Intel "i7" OVERCLOCKED , tarjetas de video triples (vinculadas), todas en Vista64 (Vista no está mal una vez que finalmente se ejecuta con todas las partes instaladas). Fue un verdadero dolor tenerlo todo listo. Pero, ya no estoy esperando en mi computadora. Velocidad de compilación pura, velocidad de carga, más una nueva máquina nueva sin toda la basura que se instaló en la última en los últimos 2 años. Incluso descargué DelphiSpeedUp. No lo necesité. Y no necesito apagar AntiVirus, ya que también hice eso, y me penalizaron con la basura de Internet. Entonces AntiVirus permanece encendido. Pura y simple, obtenga una máquina BALLS OUT. Su tiempo vale más de lo que gastará en una computadora nueva.

Tuvimos el mismo problema (o similar). Yo de nuestro paquete tiene tiempo de compilación unos 12 min. Después de los cambios, ahora hemos movido a 32 sg.

Después de muchas pruebas, encontramos que la "situación problemática" era la siguiente: en un solo paquete:

  • La unidad A usa una gran cantidad de unidades: U1, U2, U3, U4, ... U100 (Usos de la interfaz) en el mismo paquete. Esta es una unidad importante que centraliza todo el trabajo de inicialización.

  • Todas las unidades del paquete, U1, U2, U3, .., U100 usan la unidad A (uso de la implementación)

Esta "referencia circular" no proporciona errores de compilación porque los USOS son diferentes, pero causaron un gran tiempo de compilación.

SOLUCIÓN: Elimine la referencia a cada unidad, U1, U2, U3, ...., U100 en la Unidad A.

Ahora, una unidad usa una gran cantidad de unidades: U1, U2, ...., U100, pero las unidades U1, U2, ..., U100, no usan la unidad A.

Después de este cambio, el tiempo de compilación se reduce drásticamente.

Si tienes una situación similar, puedes intentar esto.

Disculpa por mi mal inglés.

Saludos.

Neftalí -Germán Estévez-

Unos años más tarde estoy luchando de nuevo con el aumento de los tiempos de compilación. Actualmente estoy usando Delphi XE4 y estoy en un punto en el que necesito absolutamente refactorizar las referencias de unidades. Pensé en una nueva forma de identificar dónde están los problemas:

Estoy usando Process Monitor de Microsoft / SysInternals para monitorear el compilador:

  1. Comienzo Process Monitor con un filtro para mostrar solo dcc32.exe (o bds.exe cuando se trabaja desde el IDE).
  2. Construyo mi proyecto desde la línea de comando.
  3. Al final, miro las operaciones CreateFile en el registro de Process Monitor.

Para cada unidad, habrá una entrada para el archivo .PAS (cuando el compilador comienza a trabajar en esta unidad) y otra para el archivo .DCU (cuando el compilador ha terminado de forma compleja con esta unidad). Al trabajar en el registro con un editor de texto y / o con Excel, puedo extraer este tipo de información:

  • Una especie de "árbol", donde puedes ver recursivamente en qué orden se han compilado las unidades.
  • Para cada unidad, la demora entre ".PAS file opened" y ".DCU file written".

Luego trato de interpretar los resultados para encontrar lugares donde hacer algunas refactorizaciones aceleraría el tiempo de compilación. No es tan fácil, pero estoy obteniendo algunos resultados alentadores.

usando Delphi 7 y 2009, la semana pasada pasé de casi 2 minutos para compilar y otros 45 segundos después de tocar f9 y obtuve la forma principal de mi aplicación hasta 20 segundos compilando y ejecutándome. Esto me ha vuelto loco durante unos 6 meses y nada de lo que intento parece funcionar. Usando filemon de SysInternals, me doy cuenta de que cada unidad (en su mayoría componentes) que el compilador requiere se buscó en cada carpeta que estaba en la ruta de búsqueda, sí, esto produce MUCHAS FileOpen, FileExists y FileNotFound, etc. Lo que hago fue poner cada DCU, DFM, RES, etc. de componentes, todos en una sola carpeta, y teniendo solo esta carpeta en la ruta de búsqueda, y un par de otras carpetas requeridas por el proyecto; los resultados fueron increíbles Otro problema antes de la corrección, fue la depuración. Se tarda casi 40 segundos en cada pulsación de tecla F7, F8 durante la depuración, esto también se ha solucionado. Espero que esta información pueda ayudarte. Saludos desde Isla de Margarita, Venezuela. Disculpe mi inglés, si hay algún error;)

  • No compilar en unidades de red. El tiempo de búsqueda es dramáticamente peor.
  • Considera apuntar tu dcu (directorio de "unidad de salida" a un ramdrive.
  • Limite la cantidad de directorios de inclusión / unidad.
  • Trate de evitar referencias circulares menores que el compilador aún acepte, especialmente para unidades grandes (por ejemplo, unidades ORM generadas para su OPF). Puede causar que las unidades grandes se compilen dos veces. (¿Delphi permite circulares mutuas menores, o es solo una característica FPC?)

Nunca lo intenté, pero la codificación de todos los archivos con ruta completa / relativa en el .dpr central también podría ayudar (script para regenerar / actualizar?). (Mencionas lo anterior, pero ¿fue con la ruta xx en la notación ''/ path / aaa''?).

Otros tiros largos:

  • Use Kylix (file / dir I / O en Linux es dramáticamente mejor en mi experiencia (aunque eso es de la experiencia de FPC)). Tal vez necesitamos un kylix cruzado revertido :-)
  • Use una máquina de compilación separada (Windows) y ajuste NTFS sobre el registro para que sea menos "seguro". (que no te importa, ya que todo es un sistema de revisión para empezar). Afaik estas opciones solo se pueden hacer globalmente para todos los sistemas de archivos, de ahí el sistema separado. Lanza un conjunto de banda o Raptor también.
  • Olvida el estado sólido. Un agradable zumbido en la atmósfera, pero la alta tasa de escritura lo matará (tanto la vida como el rendimiento cuando esté más lleno y no pueda asignar de manera óptima), y necesita los caros Intel para superar dos HD de $ 75 en RAID.

Lo siento por las referencias de FPC. Hago ambas cosas, y a veces ya no sé qué pertenece a qué.