Debuggers and profilers already exist for the developers of applications to know these things.
this tool seems much more useful for the reverse engineer who is watching memory of a target application visually while they step in a debugger. this wouldn't even be for reading specific values of RAM, again the debugger is usually quite good at that, but instead would be useful to see how things change as execution continues.
One big difference between an intermediate and an expert programmer is that an expert develops their intuition for how the program they write will compile and run. Can you guess correctly how fast, or how slow each function will be? Or what the optimizer will do a good or a bad job at optimizing? Can you tell before you've written your code when avoiding allocations is going to speed things up, and when it won't matter?
Debuggers and profilers honestly aren't very good at giving you a "zoomed out" view of whats going on in your program. Each tool shows you a specific aspect of your program, and hides everything else. For profilers, thats usually what the CPU spends its time on. For debuggers, the execution path of a single function. Godbolt shows how the optimizer works. And so on.
But from my perspective, having more tools which show different aspects of my code is almost always a win. I never know ahead of time which perspective will let me double my program's performance, or halve memory usage. Writing code is easy. Understanding code is much more complex.
So yeah, from a software development point of view I think this is neat! I want to give it a try on some of my programs because I expect to see my mental model animated back at me, and I anticipate being surprised. This looks cool!
why do people call that tool "Godbolt"? it's "Compiler Explorer."
people who don't have an eye for detail about things like this are always the ones telling me what I'm doing wrong.
I wrote a blog post last year with a working title of "CRDTs go brrr". I renamed it to something more boring before posting it, but "crdts-go-brrr' still shows up in the URL. Universally when people talk to me about that article, they use the original title. Not whatever I renamed it to.
What do I do about that? Do I get angry about it? Do I demand people stop using the catchy title I invented for my writing, then shied away from? No. The wisdom of the crowd has spoken. I accept it, learn and move on.
Matt Godbolt hosted his tool at godbolt.org, and everyone started calling it godbolt. Then he labelled it "Compiler Explorer" and ... everyone kept calling it godbolt because we remember it, and its in the URL, and its frankly a better name. Its telling that everyone (including you) knew what I meant in my comment. If I said "Compiler Explorer", I bet more people would have been confused. (I would have been confused!).
So yes, call me whatever you want. Exercise your freedom of speech boldly! But obviously, if you pick a name that other people don't recognise, you won't be understood. And if you insult me, I'll feel insulted. Its your right to do that, and my right to react however I like.
I think dumping the raw memory is usually used for debugging (postmortem?) rather than to optimize for performance.
Even if I were to debug memory using raw hex, I'd probably take a snapshot and open that in a good hex editor instead of just watching some blocks blink.
Even before that I'd scan through various parts of apple iie memory using the machine language lister. I love to troll thru ram.