C++ define un modo de lanzamiento 'mejor' incorporar VS

Question

que actualmente usa la siguiente preprocesador define, y diversos parámetros de optimización:

• WIN32_LEAN_AND_MEAN
• VC_EXTRALEAN
• NOMINMAX
• _CRT_SECURE_NO_WARNINGS
• _SCL_SECURE_NO_WARNINGS
• _SECURE_SCL = 0
• _HAS_ITERATOR_DEBUGGING = 0

Mi pregunta es ¿qué otras cosas hacen compañeros Soers utilizan, añadir, definir, con el fin de conseguir un modo de disparo acumulación de VS C++ (2008,2010) para que sea lo más performante como sea posible?

Por cierto, lo he probado en PGO, etc, pero me ayuda un poco, pero nada que comparta con GCC, tampoco estoy usando streams, el C++ del que hablo se parece más a C pero haciendo uso de plantillas y algoritmos STL etc.

Tal como está ahora segmentos de código muy simples palidecen en comparación wRT rendimiento en comparación con lo que GCC produce en decir una máquina x86 equivalente que ejecutan Linux (kernel 2.6+) utilizando 02.

Nota al margen: Creo que muchos de los problemas se relacionan directamente con la versión STL (Dinkum) proporcionada por MS. ¿Podría la gente explicar las experiencias usando STLPort, etc. con VS C++?

Answer 1

no veo cómo la inclusión de:

_CRT_SECURE_NO_WARNINGS 
_SCL_SECURE_NO_WARNINGS 

..gives que una acumulación mejor o con más prestaciones. Todo lo que está haciendo es desactivar las advertencias sobre las funciones obsoletas de MS CRT. Si está haciendo esto porque sabe lo que está haciendo y necesita un código agnóstico de plataforma, de lo contrario lo reconsideraría.

ACTUALIZACIÓN: Además, el compilador solo puede hacer tanto. Apostaría a que obtendrías más código de rendimiento si instrumentaras y arreglases tus puntos de acceso existentes en lugar de tratar de obtener pequeños porcentajes (si es que eso) ganancias de la fase de compilación y enlace.

Update2: _HAS_ITERATOR_DEBUGGING no puede utilizarse al compilar las versiones de lanzamiento de todos modos según la MSDN. WIN32_LEAN_AND_MEANVC_EXTRALEAN (y probablemente NOMINMAX aunque el rendimiento no es la principal razón para deshabilitar esto) podría darle un aumento de rendimiento, aunque el resto tiene un valor dudoso. Debe favorecer el código rápido correcto sobre (quizás - y lo insisto tal vez) un código ligeramente más rápido pero más propenso a los riesgos.