paint-brush
He aquí por qué no debería utilizar Graphviz para DAG: qué debería utilizar en su lugarpor@s0l0ist
1,129 lecturas
1,129 lecturas

He aquí por qué no debería utilizar Graphviz para DAG: qué debería utilizar en su lugar

por Nick Angelou5m2024/01/24
Read on Terminal Reader

Demasiado Largo; Para Leer

tl;dr: Utilice Vizdom.dev para representar DAG escritos en el lenguaje DOT y experimente aceleraciones de hasta 30 veces
featured image - He aquí por qué no debería utilizar Graphviz para DAG: qué debería utilizar en su lugar
Nick Angelou HackerNoon profile picture
0-item
1-item


Spoiler: use Vizdom.dev para representar DAG escritos en lenguaje DOT


Como desarrollador de software, ocasionalmente he trabajado con DAG, la mayoría de los cuales implican visualizarlos. En muchos casos, me resultó difícil obtener un renderizado rápido y me encontré buscando herramientas.


Afortunadamente, existe el confiable Grafiz herramienta que puede representar gráficos escritos en el lenguaje DOT: ¡Perfecto!


Excepto…

  • No funciona bien en la web*
  • necesito instalarlo
  • No gestiona archivos DOT/GV en línea

Consideraciones

*Bien, técnicamente Graphviz se puede compilar en WebAssembly, y algunas personas talentosas lograron construir algunos proyectos interesantes como el de Dreampuf. editor , Nikeee edotor.net y magjac editor – cada uno con su propio toque. Todavía me cuesta incrustar estas representaciones sin exportarlas a un SVG (u otro medio).


Por ejemplo, quiero almacenar mi gráfico en Noción.so simplemente pegando un enlace que representa automáticamente el gráfico.


Podría usar sirenajs que representa gráficos de manera bastante limpia y funciona sorprendentemente bien; es una de las muchas razones por las que tiene 64k+ inicios en GitHub . También puedo incrustar gráficos en Notion/GitHub usando Markdown, ¡genial!


Desafortunadamente, tengo que traducir el DOT al tipo de descuento que requiere Mermaid. Para representaciones textuales más pequeñas, puedo usar ChatGPT para convertirlas por mí, pero con frecuencia comete errores gramaticales y el gráfico se negará a representarse, lo que lo hace poco confiable como fuente de automatización.


Entonces hay Terrastruct.com lo cual es sorprendente para administrar diagramas hechos a mano , pero al igual que mis problemas con Mermaid, no puedo convertir DOT a D2 de manera confiable. Supongo que si vas a construir diagramas a mano, este es un costo único aceptable. En general, es una herramienta fantástica. ¡Prestigio!

El problema

  • Quiero representar resultados DOT generados mediante programación ; ninguna de las herramientas parece ayudarme a lograr ese objetivo.


  • Quiero insertar enlaces que representen gráficos.


  • Quiero almacenar la representación en línea para actualizarla o compararla visualmente con otros gráficos.

La solución

Sí, construí un aplicación por eso 🎉


…Y está construido íntegramente en Rust 🦀 con muchas gracias a Leptos


tl;dr : una aplicación sencilla y especialmente diseñada para renderizar DAG en línea de forma rápida


Minimizar los cruces de bordes en la generación de gráficos, un desafío NP-difícil reconocido, es clave para crear gráficos visualmente atractivos. El equipo de Terrastruct ha publicado un excelente entrada en el blog profundizando en este tema. Inspirado significativamente por los algoritmos de diseño de DagreJS y el revelador artículo " Una técnica para dibujar gráficos dirigidos ¹", desarrollé una variante en Rust.


Esta versión es particularmente efectiva para representar gráficos jerárquicos, aprovechando las intrincadas complejidades de este problema.


La renderización de DAG grandes (más de 500 nodos/bordes) tiende a ser algo lenta con Graphviz. Dagre + D3 ( d3-graphviz y derivados) terminan siendo un poco más rápidos y ofrecen excelentes animaciones y personalizaciones de estilo. Sin embargo, sentí que se pierden las características que proporciona el lenguaje DOT, es decir, los atributos de estilo a menudo solo se respetan si se renderiza con Graphviz.


vizdom producirá resultados muy similares a Dagre pero más alineados con la especificación DOT y los comportamientos de estilo de Graphviz. Sin embargo, no tiene paridad de características con Graphviz, y las declaraciones/atributos que no son compatibles simplemente se ignoran.


Creo que es un buen compromiso para los tipos de atributos que consumirá el DOT generados mediante programación.


Características de Vizdom

  • 🚀 Representación increíblemente rápida
  • 💾 Almacenar gráficos en enlaces
  • 0️⃣ Cero dependencias y no requiere instalación

Velocidad de renderizado

Bueno, es una comparación de manzanas con naranjas. Graphviz todavía produce excelentes visualizaciones y admite más motores de diseño , entonces estoy comparando subjetivamente vizdom contra el motor DOT de Graphviz, reduciéndolo a solo DAG, y aún más reduciéndolo a una lista de características limitadas del lenguaje DOT.


Sí, sé que es terrible comparar años de experiencia y herramientas en torno a la racha de más de 30 años que es Graphviz, pero para mi caso de uso limitado, es increíblemente rápido. Aquí hay algunos tiempos de pared en mi Macbook Pro M1 para renderizar un gráfico bastante grande con ~400 nodos:


  • Graphviz nativo: ~30 segundos
  • Chrome (WASM) Graphviz: falla*
  • Chrome (Javascript) DagreJS: ~10 segundos
  • Cromo (WASM) vizdom : ~1 segundo**


* Se bloquea porque el indicador de emscripten, ALLOW_MEMORY_GROWTH=1 , no está configurado, lo que limita la memoria total a 16 MB. Esto se puede solucionar, pero no he encontrado un proyecto en línea que pueda manejar el gráfico en cuestión.


** El gráfico de ejemplo se representa seleccionando Example 14 en la vista del editor. Actualizar la página hará que la actualice y obtenga un 414 porque el URI que persiste en el gráfico es demasiado grande. Estoy trabajando en una mejor solución para almacenar gráficos más grandes.


Representación SVG del Ejemplo 14

Almacenar gráficos en enlaces

Notará que cuando realiza cambios en el archivo DOT, la URL actualiza inmediatamente algunos parámetros de consulta para almacenar el gráfico y las opciones de diseño, lo que le permite siempre hacer referencia a una copia de sus datos simplemente almacenando el enlace.


Hay un problema: los gráficos grandes tienden a hacer que el URI sea demasiado grande para AWS (donde vizdom está alojado actualmente) y otros balanceadores de carga.


Actualmente estoy trabajando en una solución para manejar gráficos más grandes, pero mientras tanto, he incluido algunas formas de conservar y almacenar gráficos:


  • Copie un enlace incrustable que muestre automáticamente una vista que maximice el gráfico.


  • Copie un fragmento de iframe para incrustarlo en cualquier aplicación que admita su renderización.


  • O simplemente descargue el SVG renderizado.


A continuación se muestra un ejemplo de cómo se ve la vista del editor del traza pprof para desinflar :

Vaya a la Vista del editor y cargue Example 42


Vista diferencial

De vez en cuando, me encontraba tratando de comparar dos gráficos que había generado, así que mientras lo hacía, agregué un visor de diferencias para ver visualmente los cambios entre dos gráficos diferentes.


Leyenda de colores:

  • Rojo: eliminado
  • Naranja: Modificado
  • Verde: Añadido


Aquí hay algunas instantáneas:

Haga clic en mí: cambiar un ID de nodo de “e” a “f”


Haga clic en mí: agregando "cluster=true"


Dirección futura

vizdom Todavía es un trabajo en progreso y, a medida que continúa evolucionando, soy consciente de que el viaje para perfeccionar esta herramienta es tan dinámico como el campo de la visualización de gráficos en sí. Si bien estoy orgulloso de lo que vizdom ha logrado hasta ahora, estoy aún más entusiasmado con su potencial. Ahí es donde entra usted, el lector y usuario potencial.


Si tiene algún comentario, no dude en enviarme un mensaje a gitter o Discordia .


Gracias por leer. Si te gustó este artículo, ¡ síguelo !


[1]: ER Gansner, E. Koutsofios, SC North y K. . -PAG. Vo, “Una técnica para dibujar gráficos dirigidos”, en IEEE Transactions on Software Engineering, vol. 19, núm. 3, págs. 214–230, marzo de 1993, doi: 10.1109/32.221135.


También publicado aquí