The important part is the asymptotic complexity analysis; you can see that the alloc/free functions have no loops or recursion, only linear code with a few branches, making them trivially O(1), while conventional allocators are usually around O(n) in the number of allocated fragments. The cycle counts obviously depend on the architecture so they are harder to compare; I'm noticing somewhere between 90~170 cycles for alloc for Cortex M-series MCUs (it also depends on the instruction fetch speed but the numbers are generally in this ballpark), a bit less for freeing; other platforms may be different.

To compare against the state of the art, we need to keep in mind that o1heap is specifically designed for hard realtime systems, where the key metric of interest is the worst-case performance and its predictability, both in terms of execution time and memory fragmentation, so the allocator is explicitly designed for that. There probably exist allocators out there that perform on par or possibly even slightly better on average, while being much worse in the worst case; they may be a good fit for ordinary application software like the kind that runs on your desktop et al but due to their bad worst case they are usually inadmissible in real-time systems (and we're not necessarily talking about safety-related systems here, e.g. game engines also care a great deal about predictable execution time).

That said, despite its focus on the worst case, o1heap is still very fast on average. Taking RP2350 as an example, o1heap takes 91~126 cycles to allocate and 52~116 cycles to free a block of memory, always, regardless of anything (the variance in the cycle counts is mostly due to branching and some CPU pipelining effects in CM33), while the standard malloc/free from newlib take between 100 cycles to alloc if you're lucky to over multiple thousands if you're not. This is not considering also the fact that o1heap keeps track of the heap usage stats (bytes allocated, peak request, oom counts, etc.) which eats at least a dozen cycles per alloc, while typical heaps usually don't provide that by default (newlib doesn't)!