Fast mode for testing

[casey]

Even though redb is quite fast, we have a bunch of tests, and some of them creep up towards the 1-2 second mark, which makes the edit/test/debug loop a little slower than I'd like.

It would be nice if we could use redb with an anonymous mapping for tests, similar to sqlite's:memory: mode, which I assume would be much faster.

[cberner]

How many transactions do you commit during one of those slow tests?

[casey]

Just a handful, usually they consist of creating a dummy blockchain containing a block or two, indexing it, and then doing some queries against the index state.

[cberner]

What's an example of one of these slow tests? I hacked this into my benchmark and am skeptical this is going to help a lot. I think you could use non-durable commits and get most of the speedup:

"pre-commit" is after all the writes complete, but before the commit.

ANON mmap
redb: Bulk pre-commit loaded 1000000 items in 1674ms
redb: Bulk loaded 1000000 items in 1674ms

Durability::None
redb: Bulk pre-commit loaded 1000000 items in 1808ms
redb: Bulk loaded 1000000 items in 1808ms

Normal
redb: Bulk pre-commit loaded 1000000 items in 1789ms
redb: Bulk loaded 1000000 items in 1942ms

[casey]

Good idea! I just switched to Durability::None, and it sped up a full test run from ~4.6 seconds to ~3.3 seconds: https://github.com/casey/ord/pull/621

An example of a slow test is index::tests::height_limit, which creates two different databases with different parameters: https://github.com/casey/ord/blob/master/src/index.rs#L661

[cberner]

It did speed up that one test when run on its own. However, it doesn't seem to have a meaningful effect on the whole suite:

before:
test result: ok. 160 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.56s

after:
test result: ok. 160 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.50s

and it makes a bunch of the integration tests fail with error: I/O error: Cannot allocate memory (os error 12)

[casey]

Is it representative of the performance of an anonymous map if it's causing errors? i.e. it's not quite doing the same thing, there's a difference in behavior.

[cberner]

The 8s was for the other tests, so I don't think it included the ones that started failing. I pushed it to the "anon" branch though, so that you can try it out

[casey]

If all this will save is a few ms per test, then I think it's safe to close, since there won't be much of an improvement over just using Durability::None.