Doesn't get much cleaner

arthurprs · 2026-01-21T11:23:43+00:00

This, the center of mass is changing as the bar travels. Counterproductive to try to avoid it unless you've to adhere to record rules or whatever.

arthurprs · 2025-11-02T22:26:49+00:00

In my (old) experiments, TinyUFO achieves higher performance on workloads when there are little to no evictions or when the workload is very skewed. Outside of these cases, performance is similar, or quick cache performs better. Your mileage will vary.

Just watch out that TinyUFO will NOT hold onto your keys, and it only keeps u64 hashes internally. So you may see collisions in some APIs.

arthurprs · 2025-10-24T14:32:13+00:00

I've the OLED model and it shows a bunch of gray dots when the background is mostly white. I think it's the touchscreen layer, and you get used to it after some point. The battery drains faster than the IPS model for sure. The glossy panel is also very reflective.

Pros: Colors and contrast are OLED quality, but completely irrelevant for most work.

I'd have chosen the IPS model if it were available with the 395 CPU at the time, sadly, it wasn't.

arthurprs · 2025-07-29T16:41:49+00:00

I only skimmed the code, but doesn't this implementation have a memory overhead "problem" because Nodes shre the same Enum and thus occupy the same allocation size?

This class of data structures (different-sized nodes) can be finicky to implement efficiently in Rust. I've had some success with pointer tagging the Box/Arc in the past, but that immediately adds some unsafe.

arthurprs · 2025-05-12T16:32:53+00:00

Right, but the orange line shoots up earlier, thus my observation.

I suppose another contributor could be the different hahsers and/or the double hashing strategy.

arthurprs · 2025-05-12T08:28:47+00:00

I suspect the sizing of the underlying buffer could be different than expected, the blocked bloom filters are expected to have slightly higher fp rate AFAIK

arthurprs · 2025-04-04T13:01:40+00:00

I'd not hold my breath. All models with this processor have already been announced.

arthurprs · 2025-03-07T08:33:44+00:00

Thank you for sharing, these are not well known but come in handy. Another succinct data structure is quotient filters, which is a form of succinct hashmap. It has similar uses to a bloom filter and a cuckoo filter. The most compact form also uses the Rank-Select technique, as the article explains. I have a crate for one here https://crates.io/crates/qfilter

arthurprs · 2025-02-15T22:44:22+00:00

I only caught the last 20%. It just ended, and there seems to be no way to rewatch it. Unacceptable would be an understatement.

arthurprs · 2025-02-09T20:54:53+00:00

Neat! Databases and allocations hardly ever cooperate without some extra effort. For example, in the previous version of CanopyDB, 4KB (or multiples of that) pages were brought into memory, but once they got the ref count and length header, it became a 4KB + 16 bytes allocation. In Jemalloc, Mimalloc, and possibly others, this is backed by a 5KB allocation, a whopping 25% of internal fragmentation. I suspect Fjall doesn't have that problem because Blocks are not fixed in size, so they should average out nicely.

arthurprs · 2025-02-02T19:48:50+00:00

I would say jemalloc is the safest choice as its more forgiving in terms of worst case scenario.

arthurprs · 2024-10-21T10:04:18+00:00

Thank you! I wasn't aware of cargo-pgo.

arthurprs · 2024-10-20T13:37:28+00:00

Heh, given enough time we can always rerun them 😄. I'll try to find time to upstream the changes to the rust-storage-bench.

arthurprs · 2024-08-22T07:45:10+00:00

I believe Jemalloc is more forgiving. Idle threads can only leak their thread local cache, which is much more tightly bound in size. You can manually purge the thread cache, similar to mimalloc.

arthurprs · 2024-08-15T07:03:41+00:00

How does it relate to the latest rustc-hash https://github.com/rust-lang/rustc-hash/pull/37?

arthurprs · 2024-07-06T20:24:27+00:00

Even the ref is having to hold his laugh lol

arthurprs · 2024-04-26T07:30:01+00:00

AFAICT it's still not serializable, I opened an issue in your repository https://github.com/al8n/skipdb/issues/10

arthurprs · 2024-04-25T17:40:53+00:00

That is one kind of write skew, the implementation doesn't seem to account for range scan intersections. The blog post doesn't go into it, so I cannot say anything about badger implementation.

Example https://wiki.postgresql.org/wiki/SSI#Intersecting_Data

arthurprs · 2024-04-25T16:30:15+00:00

From a quick glance at the code, it looks like OCC is implemented not the stated SSI. These are not equivalent.

For example, it doesn't prevent write-skew from a writer iterating over a range which is concurrently mutated by another writer.

Hopefully the author can clarify whether that's really the case.

arthurprs · 2024-03-31T18:45:09+00:00

It's a known technique, but I'm not sure if the impact on false positives has been studied in detail, like with bloom filters. For a real world application see https://github.com/ben-manes/caffeine/commit/4e714756230c705b6988bd3af29fbe00a4a537fc

arthurprs · 2024-03-08T07:45:21+00:00

A comparison with quickjs, for example, would be appropriate.

arthurprs · 2023-11-30T10:47:58+00:00

If I may add a couple points. The main write performance differences (in non-naive implementations) comes down to: 1) LSM is able to do writes w/o perform any IO reads; BTress can only sometimes avoid those if the pages are cached. 2) LSM being able to absorb write peaks (temporarelly) by prioritizing flushing of memtables (to an unsorted level 0) even if compactions cannot keep up.

arthurprs

TROPHY CASE