ctrie-java VS pyroscope

Concurrent tries with non-blocking snapshots [0]

Say that you have a dataset that needs to be ordered, easily searchable, but is also updated quite frequently. Fast accesses are a pain if you decide to use traditional read-write locks.

Ctries are entirely lock-free, thus there is no waiting for your read operations when an update is happening, i.e. you run lookups on snapshots while updates happen.

They are also a lot of fun to implement, especially if you aren't familiar with lock-free algorithms! I did learn a lot doing it myself [1]

[0] http://aleksandar-prokopec.com/resources/docs/ctries-snapsho...

[1] https://github.com/mabeledo/ctrie-java

What do you mean? pyroscope.io was slow for you? or the blog?

Tries (or prefix trees).

We use them a lot at Pyroscope for compressing strings that have common prefixes. They are also used in databases (e.g indexes in Mongo) or file formats (e.g debug symbols in macOS/iOS Mach-O format are compressed using tries).

We have an article with some animations that go into details about tries in case anyone's interested [0].

[0] https://github.com/pyroscope-io/pyroscope/blob/main/docs/sto...

You could use continuous profiling with Pyroscope which uses async-profiler under the hood, but with the added functionality that you can add relevant tags to your VMs (example).

Java Flight Recorder (JFR) is a format for collecting diagnostic and profiling data from Java applications. A while back someone created an issue for Pyroscope , an open source continuous profiler written in Go, to support ingesting profiles in JFR format, but there were no existing parsers that were also written in Go.

This cloud version is actually a slimmed-down version of Pyroscope which is open source and so you can run it locally.

At Pyroscope (open source continuous profiling) we use flamegraphs extensively to visualize and analyze profiling data. However, one of the worst parts about using flamegraphs for analysis is that they are kind of annoying to share.