VisualVM vs .NET Tooling

¿Por qué en Java hay “una herramienta” y en .NET hay muchas?

Cuando venís del mundo Java, es muy común preguntarte: ¿Dónde está el VisualVM de .NET?

La respuesta corta es: no existe uno solo.

La respuesta interesante es: no existe por diseño.

En el ecosistema Java, herramientas como VisualVM se volvieron estándar porque la JVM expone un modelo bastante unificado:

• JMX (Java Management Extensions)
• Heap dumps
• Thread dumps
• GC metrics

Todo eso se puede consumir desde una sola herramienta.

¿Qué ofrece VisualVM?

• Profiling de CPU
• Análisis de memoria (heap)
• Monitoreo de threads
• Plugins

Resultado: una experiencia “tipo panel de control” donde ves todo.

En .NET moderno, el enfoque es distinto. En lugar de una herramienta central, tenés un ecosistema de herramientas especializadas.

Visual Studio (Profiler integrado)

Es lo más parecido a VisualVM:

• CPU profiling
• Memory profiling
• Timeline
• UI completa

Es la opción más “todo en uno”, pero:

❌ Es pesada

❌ No siempre usable en producción

CLI tools (el corazón real de .NET)

.NET adopta un enfoque más tipo Unix:

• dotnet-counters → métricas en vivo
• dotnet-trace → trazas de ejecución
• dotnet-dump → dumps
• dotnet-gcdump → GC
• dotnet-stack → threads

Cada herramienta hace una cosa… pero la hace muy bien.

Esto permite:

• Usarlas en producción
• Automatizarlas
• Integrarlas con pipelines

PerfView

• Muy potente
• Usado internamente por Microsoft
• Basado en ETW (Event Tracing for Windows)

❌ Curva de aprendizaje alta

❌ UX poco amigable

Herramientas comerciales

• dotTrace
• ANTS Profiler
• .NET Memory Profiler

Estas sí se sienten más como VisualVM:

✔️ UI amigable

✔️ Experiencia integrada

❌ Son pagas