Show HN: Spall – WASM-based profiler for JavaScript and C and Odin

Show HN: Spall – WASM-based profiler for JavaScript and C and Odin(gravitymoth.com)

83 points by crdavidson 3 years ago | 17 comments

[I'm the author] Spall is a web-accessible profiler that I made to help my web-dev friends load gigabyte+ JSON traces without lunch-break-long load times. Recently, Spall got experimental support for auto-tracing with binary traces (along with an in-progress native-port, to give it more memory headroom), which was used to help track down and fix some hard-to-spot lock contention issues in the Odin-language compiler.

I demoed it at the Handmade Seattle conference in October, https://guide.handmade-seattle.com/c/2022/spall/, with a head-to-head against Perfetto, another big web profiler.

I'll be around to answer any questions. Thanks for looking at my project! If you like Spall, you can catch my other projects over at https://colrdavidson.github.io/.

If you happen to be hiring I'd love to hear from you. Looking for something fun and new to do after a long sabbatical, working on cool open-source projects!

qgc 3 years ago |

The comparison with Perfetto in the video is pretty damn impressive. So nice to have another player in the profiler space. Iteration time is unfortunately (and inexplicably) undervalued. My short time messing around with SpeedScope was more promising, but profiling in general has been pretty painful with all of the tools I've tried that ingest auto-traced input.

You mention in the "For Everyone Else" section that you have an auto-tracer system to instrument all your tracing. Aside from being very handy, how does it compare to [1] which you mention right after?

[1] https://github.com/bvisness/dtrace2spall

crdavidson 3 years ago | |

So, dtrace2spall is going to generate much smaller files and impact runtime less, because it samples with dtrace, and then converts the data to spall's format as a post-pass.

Auto-tracing is far more comprehensive, but it's a big datadump, and it does impact runtimes a bit more.

So far I've mostly used auto-tracing to figure out how bigger pieces of code work, rather than strictly for profiling. It was super helpful trying to walk through the more complicated parts of the Odin compiler to fix things, being able to see the order of functions called on the timeline.

gavinray 3 years ago |

I recently read about this on the Odin monthly news, it was super impressive!

In the section of the interview where you talk about the difficulties you had, you discuss the challenges of making Odin work properly on WASM, and how you needed custom memory-management and allocation strategies.

Could you talk some more about that experience and the general process of working with that sort of low-level bit in Odin? I've been experimenting with using Odin to write a DB from scratch.

crdavidson 3 years ago | |

Sure! So far, Odin has been awesome for doing custom allocation. Everything in the core library that allocates takes an optional allocator parameter, which means that you can use quite a few of the core libraries comfortably even in embedded contexts, and make it all sit on top of an arena in WASM's weird memoryland if you need to without an issue.

Outside of the WASM context where Odin runs into some difficult friction, systems-level work has been reasonable. I wrote a good chunk of a C/DWARF debugger in both C and Odin to compare, and Odin was by far the more pleasant language to write it in, my Odin code was much smaller because I didn't need xmacros, and I had proper namespaced enums, tagged unions, and slices, but still looked/read pretty similarly to well-written C or Go. I did have to wrap a few syscalls myself though, because the core library doesn't quite cover things like ptrace or networking yet.

I've put a fair bit of work into getting cross-platform networking into Odin's core library, hopefully we'll see it show up soon enough, and get some of those common nice-to-haves crossed off.

gavinray 3 years ago | | |

Awesome, thanks for the reply! Looking forward to seeing those hit core hopefully!

matiasfernandez 3 years ago | | |

Impressive work! Where is the net package getting worked on? Is it the "core_net" branch or do you have your own fork?

4984 3 years ago | |

The interview in question, for those interested: https://odin-lang.org/news/newsletter-2022-12/#interview-wit...

jerryu 3 years ago |

Web profilers definitely could use some disruption. Congratulations on the release. I am going to forward this to a friend who is actively hiring.

skytrias 3 years ago |

Hyped about the auto-tracing feature! The current version of spall has been very useful to me for some quick performance measurements.

IshKebab 3 years ago |

Very cool. JSON is clearly a terrible format for this though. I've had great success using SQLite instead. You mentioned binary formats in the video - what other formats are supported? Last I looked the whole chrome://tracing ecosystem was stubbornly stuck with JSON.

crdavidson 3 years ago | |

So, spall has a JSON parser to help all the poor folks stuck using JSON or the chrome devtools profiler, who still need to keep using it.

For everyone doing new things, there's a binary format which is pretty straightforward.

The binary side supports begin and end events, which are defined here: https://github.com/colrdavidson/spall/blob/master/formats/sp...

and the header library mirrors those structs, and chalks out the interfaces around here: https://github.com/colrdavidson/spall/blob/master/spall.h#L2...

Basically, it's a small header, and then events, plopped one after another into the file. Each thread gets a buffer to store events as they come in, and they get written as atomic chunks with fwrite/append, so threads never have to interact directly.

In practice, the overhead for tracepoints with the binary format is super low, depending on the machine on x86, we've seen somewhere between 12-20ns for begin+end trace overhead when compiled with clang (+ occasional disk flush overhead, if you're generating a ton of data). I believe I can get that overhead even smaller to get things nice and lightweight, it's a major goal of mine to be able to trace 10+ million events per second without impacting runtimes significantly, so that bigger projects can be comfortably fully auto-traced.

IshKebab 3 years ago | | |

Ah neat. Have you ever used RAD Tools Telemetry (http://www.radgametools.com/telemetry.htm)? I saw Jonathan Blow using it on Youtube once and it looked slick and performant like Spall (and unlike every other open source option).

metadat 3 years ago |

In case you're like me and never heard of the Odin PL:

https://odin-lang.org/docs/overview/

gavinray 3 years ago | |

If you want a tl;dr

It's a systems programming language that syntactically feels similar to Go and Jonathan Blow's unreleased language, Jai.

It is meant to be a C replacement (or, on the same level as C), similar to Zig.

slekker 3 years ago |

On Safari/iOS, the webpage to the demo really doesn’t let me scroll down and keeps going back up :(

abnercoimbre 3 years ago | |

Hey I'm the organizer for the Handmade conference. I'll look into it. In the meantime there's a direct [0] Vimeo link.

[0] https://vimeo.com/776796857