4 ms·

I didn't know that, thank you for kindly enlightening me! So from the blogpost, the "compiler debug dumps" are the optimized graph data struct, and instead of c

• jimsmart 6y ago
  I suspect this may have originally developed as a debugging aid, your “to better understand and improve the compiler”, but also to better understand how Ruby programs execute. With non-trivial data structures and algorithms (such as sea-of-nodes here), being able to visually introspect statically, and/or visualise its operation dynamically, can often provide informative insights. Instead of, or perhaps as well as, converting to assembly or byte code, here the author is producing a visualisation of the internal graph structure contained within the compiler. The graph isn’t necessarily a one-to-one match with the AST derived from the source, due to graph transformations that take place during the optimising phase of the compiler/runtime. This makes it even more important/interesting to see what is going on under the hood. Usually, in high-level programming languages one rarely has concerns regarding how easily the compiler might deal with the code - one just codes, and uses language features appropriately, as needed. With the only caveat here being the extreme performance crew, e.g. games programmers might use a restricted subset of C++, and also might disassemble compiler output, and use that information to help try and optimise their source somewhat.