Me doy cuenta de que el código Java será slow down cuando se ejecuta en el depurador.¿La aplicación Java se ralentizará por la presencia de -Xdebug o solo cuando se pasa por el código?
La pregunta es, ¿el código de frenar simplemente iniciando Java con estas opciones:
??
¿O la ralentización solo ocurre cuando se conecta al "puerto de depuración" y realmente pasa el código usando un IDE?
En primer lugar, para responder estrictamente a su pregunta - al menos como se indica en su título - -Xdebug única habilita la compatibilidad con la depuración en la máquina virtual usando JVMDI en las JVM antes de la 5.0. Entonces, en sí mismo, no hace mucho. Por otra parte, es JVMDI deprecated since 5.0 a favor de JVMTI:
- Xdebug
de inicio con soporte para JVMDI habilitado. JVMDI ha quedado en desuso y no se usa para la depuración en J2SE 5.0, por lo que esta opción no es necesaria para la depuración en J2SE 5.0.
Así -Xdebug no hace nada más y la parte importante es:
-Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...
o, a partir de Java 5.0, la más reciente (que se debe preferir como agente JDWP en 5.0 utiliza el JVM interfaz de TI a la máquina virtual en lugar de la interfaz JVMDI mayores):
--agentlib:jdwp=<name1>[=<value1>],<name2>[=<value2>]...
Ahora, que yo sepa, solo loading the jwdp agent y/o configuración de la JVM para escuchar para una conexión de socket en un determinado p No tiene ningún impacto notable en el rendimiento. Pero conectar un depurador sí.
No, simplemente habilitar el puerto de depuración no tendrá ningún efecto en el rendimiento del tiempo de ejecución. Al menos nunca me he dado cuenta.
..
esa no es la cuestión que está pidiendo, que habla sobre el lanzamiento de la JVM con opciones de depuración –
@Valentin - ¿eh?¿Qué? Explique por qué las líneas de comandos no habilitan un puerto de depuración y, por lo tanto, responden a la consulta. – Egwor
bien, parece que tuve un caso repentino de "mierda en mis ojos" ... @ jarnbjo: ¿podría simplemente hacer una edición vacía de su respuesta, para poder eliminar mi voto? –
resultados de las pruebas de rendimiento de AMD indican que simplemente permitiendo que el agente de depuración a través de la línea de comandos JVM hace causa una degradación del rendimiento independientemente de tener un depurador conectado a ella, y que la degradación puede ser bastante grande, dependiendo de la carga de trabajo:
Tenga en cuenta que en realidad no estábamos conectando un depurador cuando estábamos midiendo el rendimiento, por lo que habíamos asumido que esta opción agentlib sería neutral al rendimiento en este escenario de uso. Cuando eliminamos esta opción , tanto la utilización de la CPU como el rendimiento en esta carga de trabajo (medido en solicitudes manejadas por segundo) mejoraron dramáticamente.
ven su informe:
Cuando el proceso de JVM se ejecuta por mucho tiempo (algunos días/semanas), la desaceleración es definitivamente visible. Mi contexto: aplicación GWT con Oracle back-end, Java 7 en la Zona Solaris. –
El artículo de AMD ha caído de la web, pero aún se puede encontrar en la máquina de retorno aquí: https://web.archive.org/web/20160316201129/http://developer.amd.com/resources/documentation-articles/articles-whitepapers/java-performance-when-debugging-is-enabled / – tul
Incluso cargar el agente jwdp sin asociar un depurador [puede tener una penalización de rendimiento] (http://developer.amd.com/resources/documentation-articles/articles-whitepapers/java-performance-when-debugging-is-enabled/) – nodmonkey