Note about "Write-Ahead Log" (WAL) mode: The SQLite WAL mode has a
bunch of advantages that are quite nice to have:
1. WAL is significantly faster in most scenarios.
2. WAL provides more concurrency as readers do not block writers and a
writer does not block readers. Reading and writing can proceed
concurrently.
3. Disk I/O operations tends to be more sequential using WAL.
4. WAL uses many fewer fsync() operations and is thus less vulnerable
to problems on systems where the fsync() system call is broken.
The downsides of WAL mode don't really affect us. So let's turn it on.
More info: https://www.sqlite.org/wal.html
Co-authored-by: Jonas Platte <jplatte@matrix.org>
Co-authored-by: Damir Jelić <poljar@termina.org.uk>
* Move swift build scripts into xtask (#1201)
* fix(ffi): use target_path from `cargo metadata` rather than guessing
* ci(ffi): install necessary target arch for build-framework test
* feat(xtask): copy to target without rsync.
… for matrix-sdk, matrix-sdk-base, matrix-sdk-common and matrix-sdk-crypto.
matrix-sdk-indexeddb as well as the JS bindings and wasm_command_bot are
left as-is because they will likely always require JS.
> [`cargo-nextest`](https://nexte.st/index.html) is a next-generation
> test runner for Rust projects.
This patch installs and uses `nextest` to run our own tests.
Comparing `cargo test` and `cargo nextest` with hyperfine provides the
following results:
```sh
$ hyperfine 'cargo test --workspace' 'cargo nextest run --workspace && cargo test --doc'
Benchmark 1: cargo test --workspace
Time (mean ± σ): 51.785 s ± 2.066 s [User: 183.471 s, System: 10.563 s]
Range (min … max): 49.151 s … 56.641 s 10 runs
Benchmark 2: cargo nextest run --workspace && cargo test --doc
Time (mean ± σ): 44.556 s ± 0.894 s [User: 192.213 s, System: 11.441 s]
Range (min … max): 43.170 s … 45.762 s 10 runs
```
Benchmark 2 is 1.16 times faster than Benchmark 1.
