¿Por qué rara vez se utiliza la depuración inversa? [cerrado]

Por un lado, ejecutar en modo de depuración con grabación es muy costoso en comparación con el modo de depuración incluso normal; También consume mucha más memoria.

Es más fácil disminuir la granularidad desde el nivel de línea al nivel de llamada de función. Por ejemplo, el depurador estándar en eclipse le permite "soltar al marco", que es esencialmente un salto al inicio de la función con un restablecimiento de todos los parámetros (no se revierte nada en el montón, y finally bloquea no se ejecutan, por lo que no es un verdadero depurador inverso; tenga cuidado con eso).

Tenga en cuenta que esto ha estado disponible durante varios años y funciona de la mano con el reemplazo de códigos en caliente.

Para obtener una descripción general de las opciones y productos tecnológicos, vea una serie de publicaciones del blog que escribí hace un año (y algunas de las siguientes):

• enlace : la tecnología
• enlace - investigación
• enlace - productos
• enlace : actualizaciones de la publicación anterior

Mi sensación de por qué se usa tan poco es que requiere un hardware especial, o usar un depurador especial, o configurar su sistema correctamente. La mayoría de las personas no invierten el tiempo para obtener el máximo valor de sus herramientas de depuración, desafortunadamente.

Y el hecho de que el "default barato" de gdb es inusualmente lento y tiene bastantes problemas de estabilidad para todo menos los sistemas de destino más comunes.

Como ya se mencionó, el rendimiento es clave, por ejemplo. con la depuración reversible de gdb, ejecutar algo como gzip ve una desaceleración de 50,000 veces en comparación con la ejecución nativa. Sin embargo, existen alternativas comerciales: trabajo para Deshacer deshacer.io , y nuestro producto UndoDB hace lo mismo pero con una desaceleración de menos de 2x. También hay otros depuradores comerciales reversibles disponibles.

Por mi experiencia como ingeniero de ventas para el depurador TotalView, la gente sabe que existe, pero no cree que funcione, independientemente de la desaceleración (aceptable o no).

La Universidad de Cambridge recientemente realizó una encuesta titulada "Incapacidad de adoptar los costos de depuración inversos en la economía mundial $ 41 mil millones anuales" .

Y volviendo a GDB, he escuchado (mucho) que la desaceleración hace que sea bastante inutilizable en una aplicación de la "vida real".

Personalmente, me encantaría recibir noticias de más personas que utilizan la depuración inversa en aplicaciones que no sean "Hello world!"

Creo que es importante ampliar un poco más esta depuración "inversa" o "histórica". Creo que entender los sistemas complejos y el comportamiento en ellos, reproducir los "eventos" que hacen que el estado sea explícito es absolutamente crucial.

Lo que quiero expresar es que no estás solo al preguntarte por qué esta técnica no se aplica tanto hoy o por qué los problemas relacionados rara vez se discuten con claridad.

Entonces, enfaticemos dos conceptos muy importantes aquí:

1. Para entender un sistema de programación, es útil hacer explícito el estado

2. Para comprender mejor un sistema de programación, la reproducción de secuencias de estado (eventos) puede ayudar mucho.

Aquí hay algunas fuentes que abordaron el problema y propusieron o diseñaron soluciones para el problema (tratar el estado en sistemas complejos):

-Fuera del bit de alquitrán, papel: enlace Ideas principales: evitar, aislar o hacer explícito el estado

-CQRS enlace Esta es una combinación de dos conceptos: Separación de consulta de comando y Abastecimiento de eventos. Existen diferentes implementaciones (Java, C #, Scala). La repetición de las secuencias de Tate y la evolución de un modelo de dominio son las partes cruciales aquí.

Si usted realmente se aleja y ve la imagen muy amplia, ya puede ver que con el "aumento" de la programación funcional las personas ya están ((des) conscientemente) atraídas por fp porque hace que el estado ¡explícito! Pero eso solo se relaciona con el punto uno, para abordar el segundo necesita otro concepto que podría describirse "libremente" como programación reactiva funcional.

Entonces, podrías decir todo muy bien, pero ¿quién usa CQRS y FRP? Diría que (IMO porque no tengo números concretos) en realidad muchas empresas es simplemente que no saben qué trabajo tienen en esta terminología. Tal vez busques un poco en Google y escuches de empresas que usan CQRS, ya hay algunas historias de éxito. FRP también está aumentando lentamente como un ejemplo que podría dar a Netflix: enlace Que acaba de lanzar una implementación de RX que en realidad está basada en .NET (pero también tiene una implementación de Javascript). Así que la gente ya está utilizando estas técnicas hoy, EN GRANDE, para comprender sistemas complejos y mejorarlos aún más. Es por eso que utilizan técnicas de depuración inversa.