-
Notifications
You must be signed in to change notification settings - Fork 223
Reduced reallocations when reading from IPC (~12%
)
#1105
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1105 +/- ##
========================================
Coverage 81.33% 81.34%
========================================
Files 366 367 +1
Lines 35337 35458 +121
========================================
+ Hits 28742 28842 +100
- Misses 6595 6616 +21
Continue to review full report at Codecov.
|
The failed test doesn't seem to be related. |
Thanks, this is awesome! On my github it shows a diff that seems related to a missing rebase? |
Will have to change a few functions to that we make can know the tot read length. Before this was the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love it.
Left some minor comments, but otherwise ready to go.
Any benches worth mentioning?
Co-authored-by: Jorge Leitao <jorgecarleitao@gmail.com>
Co-authored-by: Jorge Leitao <jorgecarleitao@gmail.com>
Co-authored-by: Jorge Leitao <jorgecarleitao@gmail.com>
src/io/ipc/read/common.rs
Outdated
// exponential growing strategy | ||
// benchmark showed it was ~5% faster | ||
// in reading lz4 yellow-trip dataset | ||
self.data = vec![0; length * 2]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exponential growing strategy can prevent expensive reallocation. This was 5% faster on the whole file read.
12%
performance gain
12%
performance gain~12%
performance gain
Yes! This is reading lz4 compressed yellow trip taxi dataset. main
linear (or no?) growing strategy
Exponential growing strategy (same as vec)
|
I will clean this up later today and let you know when its ready. |
Good to go on my side. 👍 |
~12%
performance gain~12%
)
This is amazing, when using latest arrow2 branch against Polars, with lazy IPC Stream against 241 Streaming Arrow files totalling 1gb dataset dropped over 10% to scan! 🎉 edit: Further testing and benchmarking shows a 27% reduction 😮 |
We used
data.clear()
which sets the length to0
and then usedata.resize(len, 0)
, so that every bytes was overwritten with zero before reading.However, we can simply keep the
vec
at the maximum length and write to a slice, growing if needed. The bytes that are already initialized don't have to be reset because we will overwrite them in the subsequentread
operation.I want to add the same for parquet in a following PR.