

Visualising an Asynchronous Monad - astrada
http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/

======
poseid
nice demos, these feel a bit like playing with an oscilloscope

~~~
avsm
It goes beyond just demos... we can apply this to a vast number of OCaml
Mirage libraries and speed things up quite a lot.

One of the nice things about OPAM (the OCaml package manager) is that it can
recompile upstream library dependencies if some new optional features gets
inserted downstream. In this case, Thomas has put together a "lwt.profiling"
library that adds profiling hooks, and then every upstream Mirage library gets
systematically recompiled against this new functionality.

This way we can have profiling-free production code, and then just "opam
install mirage-profiling" and have a coffee while everything gets
instrumented. This is going to be incredible as we hook up more complex
distributed unikernel-based systems.

~~~
edwintorok
Interesting, would it make sense to store/convert the trace in the CTF
format[0]? Would the viewers from LTTng[1] be useful in analyzing this trace
data?

[0] [https://www.efficios.com/babeltrace](https://www.efficios.com/babeltrace)
[1] [http://lttng.org/files/lttv-
doc/user_guide/c42.html#mainwind...](http://lttng.org/files/lttv-
doc/user_guide/c42.html#mainwindow)

~~~
talex5
Thanks for the links. I haven't used these tools - are they useful? Which
features are most helpful? Certainly we'll want to convert to or from some
Linux trace format to combine traces that involve Linux and Mirage machines.

~~~
edwintorok
I've tried LTTng once, but it was quite complicated to set up, and required
patching the kernel. It seems they improved that, it only needs a kernel
module so I might give it another try.

I also used 'perf timechart'[0] in the past, or rather I tried to, but the
traces on any realistic workload generated SVG files so large that it was too
slow to open in firefox/inkscape etc. Your approach seems to be more scalable
as it doesn't generate one huge image/SVG but rather generates that zoomable
view via Javascript on-the-fly, right?

[0]
[http://web.archive.org/web/20130729151516/http://blog.fenrus...](http://web.archive.org/web/20130729151516/http://blog.fenrus.org/?p=5)

~~~
talex5
I've used bootchart and had the same problem. You really need to generate the
display dynamically to make the zooming work. Some other things my viewer does
that don't work with static SVG:

\- Show labels at a readable size, whatever the zoom.

\- Keep labels within the screen bounds where possible rather than letting
them scroll off.

\- Fade out large-scale features (e.g. arrows spanning long time frames) when
you get close, so they don't blot out everything in between.

\- Project y values through tanh so you can see everything at once, but focus
on the bit you're interested in.

Of course, there are other opportunities for adding interaction too.

