lista - codigos de c++ y sus funciones
Análisis de archivos MAP: ¿de dónde viene mi código? (5)
Las plantillas, macros, STL en general, todos usan una gran cantidad de espacio. Considerado como una gran biblioteca universal, BOOST agrega mucho espacio a los proyectos. BOOST_FOR_EACH es un ejemplo de esto. Sus cientos de líneas de código de plantilla, que podrían evitarse simplemente escribiendo un asa correcta de bucle, que en general es solo unas pocas teclas más.
Obtenga Visual AssistX para guardar el tipeo, no usando plantillas. También considere poseer el código que usa. Las macros y la expansión de la función en línea no necesariamente aparecerán.
Además, si puedes, aléjate de la arquitectura DLL para vincular estáticamente todo en un ejecutable que se ejecuta en diferentes "modos". No hay absolutamente nada de malo en utilizar la misma imagen ejecutable tantas veces como desee simplemente pasando un parámetro de línea de comando diferente según lo que desee que haga.
Las DLL son el peor culpable de perder espacio y ralentizar el tiempo de ejecución de un proyecto. La gente piensa que ahorra espacio, cuando de hecho tienden a tener el efecto opuesto, a veces aumentando el tamaño del proyecto en diez veces. Además aumentan el intercambio. Use secciones de código fijo (sin sección de reubicación) para el rendimiento.
Estoy buscando una herramienta para simplificar el análisis de un archivo de mapa enlazador para un gran proyecto de C ++ (VC6).
Durante el mantenimiento, los binarios crecen constantemente y quiero averiguar de dónde viene. Sospecho que una expansión de plantillas exagerada en una biblioteca compartida entre diferentes DLL, pero jsut browsign el archivo de mapa no da buenas pistas.
¿Alguna sugerencia?
El archivo de mapa debe tener el tamaño de cada sección, puede escribir una herramienta rápida para ordenar los símbolos por este tamaño. También hay una herramienta de línea de comandos que viene con MSVC (undname.exe) que puede usar para exigir los símbolos.
Una vez que tenga los símbolos ordenados por tamaño, puede generar esto semanalmente o diariamente a su gusto y comparar cómo ha cambiado el tamaño de cada símbolo a lo largo del tiempo.
El archivo de mapa solo de una sola compilación puede no decir mucho, pero un informe histórico de los archivos de mapas compilados puede decirle bastante.
No hay sugerencias para una herramienta, pero se adivina una posible causa: ¿tiene habilitada la vinculación incremental? Esto puede causar expansión durante construcciones posteriores ...
El enlazador quitará los símbolos no utilizados si está compilando con / opt: ref, por lo tanto, si usa eso y no utiliza el enlace incremental, esperaría que la expansión de los binarios solo fuera un resultado del nuevo código real que se agrega. Hasta donde sé ... espero que ayude un poco.
¿Has intentado usar dumpbin.exe en tus archivos .obj?
Cosas para buscar:
- ¿Usando mucho STL?
- ¿Muchas clases de c ++ con métodos en línea?
- Muchas constantes?
Si algo de lo anterior se aplica a usted. Verifique si tienen una amplia visibilidad, es decir, si se usan / ven en partes grandes de su aplicación.
Este es un maravilloso compilador generado herramienta de análisis / explorador / visor de archivos de mapas. Compruebe si puede explorar el archivo de mapa generado gcc.
amap: una herramienta para analizar archivos .MAP producidos por el compilador de Visual Studio de 32 bits e informar la cantidad de memoria utilizada por los datos y el código. Esta aplicación también puede leer y analizar archivos MAP producidos por los compiladores Xbox360, Wii y PS3.