Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

snapshot: delegate reading to arrow/parquet readers #590

Closed
wants to merge 1 commit into from

Conversation

asubiotto
Copy link
Member

@asubiotto asubiotto commented Nov 16, 2023

We were previously copying all snapshot part bytes into a slice that was then passed to arrow readers (parquet copies are left untouched, see #590 (comment)). This was an unnecessary indirection and resulted in extra allocations on startup. Benchmark results on recovery from snapshot only:

goos: darwin
goarch: arm64
pkg: github.com/polarsignals/frostdb
          │  benchmain   │              benchnew              │
          │    sec/op    │   sec/op     vs base               │
Replay-12   1680.6m ± 5%   816.0m ± 3%  -51.45% (p=0.002 n=6)

          │   benchmain   │              benchnew               │
          │     B/op      │     B/op      vs base               │
Replay-12   2382.9Mi ± 0%   633.0Mi ± 0%  -73.43% (p=0.002 n=6)

          │  benchmain   │              benchnew              │
          │  allocs/op   │  allocs/op   vs base               │
Replay-12   20.807M ± 0%   5.623M ± 0%  -72.98% (p=0.002 n=6)

@asubiotto asubiotto requested review from thorfour and brancz November 16, 2023 14:14
@asubiotto
Copy link
Member Author

asubiotto commented Nov 16, 2023

This doesn't seem to quite work because we close the file right after loading the snapshot and parquet reads lazily. Maybe we should keep the file open? The issue is that we might have a bunch of hidden memory that we don't know about until we go to read these parquet row groups.

@asubiotto
Copy link
Member Author

asubiotto commented Nov 23, 2023

Modified to only avoid the copy for arrow parts and it seems like the numbers are even better (there was a bug):

goos: darwin
goarch: arm64
pkg: github.com/polarsignals/frostdb
          │  benchmain   │              benchnew              │
          │    sec/op    │   sec/op     vs base               │
Replay-12   1680.6m ± 5%   816.0m ± 3%  -51.45% (p=0.002 n=6)

          │   benchmain   │              benchnew               │
          │     B/op      │     B/op      vs base               │
Replay-12   2382.9Mi ± 0%   633.0Mi ± 0%  -73.43% (p=0.002 n=6)

          │  benchmain   │              benchnew              │
          │  allocs/op   │  allocs/op   vs base               │
Replay-12   20.807M ± 0%   5.623M ± 0%  -72.98% (p=0.002 n=6)

We were previously copying all snapshot part bytes into a slice that was then
passed to arrow readers. This was an unnecessary indirection and resulted in
extra allocations on startup. Note that parquet bytes are still fully copied
since we cannot read those lazily (underlying file is closed after reading from
snapshot).
Benchmark results on recovery from snapshot only:
```
goos: darwin
goarch: arm64
pkg: github.com/polarsignals/frostdb
          │ benchmain  │             benchnew              │
          │   sec/op   │   sec/op    vs base               │
Replay-12   1.681 ± 5%   2.545 ± 4%  +51.41% (p=0.002 n=6)

          │  benchmain   │              benchnew              │
          │     B/op     │     B/op      vs base              │
Replay-12   2.327Gi ± 0%   2.278Gi ± 0%  -2.11% (p=0.002 n=6)

          │  benchmain  │             benchnew              │
          │  allocs/op  │  allocs/op   vs base              │
Replay-12   20.81M ± 0%   20.79M ± 0%  -0.10% (p=0.002 n=6)
```
@asubiotto
Copy link
Member Author

Closing since after fixing the bug the improvement is not really noticeable/worth it:

goos: darwin
goarch: arm64
pkg: github.com/polarsignals/frostdb
          │ benchmain  │             benchnew              │
          │   sec/op   │   sec/op    vs base               │
Replay-12   1.681 ± 5%   2.545 ± 4%  +51.41% (p=0.002 n=6)

          │  benchmain   │              benchnew              │
          │     B/op     │     B/op      vs base              │
Replay-12   2.327Gi ± 0%   2.278Gi ± 0%  -2.11% (p=0.002 n=6)

          │  benchmain  │             benchnew              │
          │  allocs/op  │  allocs/op   vs base              │
Replay-12   20.81M ± 0%   20.79M ± 0%  -0.10% (p=0.002 n=6)

@brancz
Copy link
Member

brancz commented Nov 23, 2023

Did you forget to close?

@asubiotto asubiotto closed this Nov 23, 2023
@asubiotto asubiotto deleted the alfonso-alloc branch May 17, 2024 11:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants