Sample column types when finding multithreaded row chunks #688
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is another optimization I've wanted to do for a while; we're already checking up to 5 rows from various locations in the file to find row boundaries for multithreaded parsing, so this just also samples the types from those locations. The end result is that we already go into full parsing having checked `tasks * 5` # of rows for column types. The 2 main advantages of adding this are that we can avoid running `detect` in all tasks in some cases, i.e. if we've already sampled that a column is `Int64`, then each task will immediately start parsing `Int64`s instead of having to `detect`, then `allocate`, etc. The other advantage is if we happen to catch a rogue string value in a part of the file, it can be promoted immediately instead of having to parse entire chunks as, say, `Int64`, and then re-parsed later. It's not super robust in that case because we're only sampling 5 rows from each chunk, but it's better than nothing and doesn't add extra cost to what we're already doing. This PR also adds an optimization when a `PooledString` column is promoted to `String`, we don't need to reparse, but can just allocate the `String` array and put the ref values in directly according to the codes.
Codecov Report
@@ Coverage Diff @@
## master #688 +/- ##
==========================================
+ Coverage 84.28% 84.84% +0.55%
==========================================
Files 10 10
Lines 1801 1847 +46
==========================================
+ Hits 1518 1567 +49
+ Misses 283 280 -3
Continue to review full report at Codecov.
|
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is another optimization I've wanted to do for a while; we're
already checking up to 5 rows from various locations in the file to find
row boundaries for multithreaded parsing, so this just also samples the
types from those locations. The end result is that we already go into
full parsing having checked
tasks * 5# of rows for column types. The2 main advantages of adding this are that we can avoid running
detectin all tasks in some cases, i.e. if we've already sampled that a column
is
Int64, then each task will immediately start parsingInt64sinstead of having to
detect, thenallocate, etc. The other advantageis if we happen to catch a rogue string value in a part of the file, it
can be promoted immediately instead of having to parse entire chunks as,
say,
Int64, and then re-parsed later. It's not super robust in thatcase because we're only sampling 5 rows from each chunk, but it's better
than nothing and doesn't add extra cost to what we're already doing.
This PR also adds an optimization when a
PooledStringcolumn ispromoted to
String, we don't need to reparse, but can just allocatethe
Stringarray and put the ref values in directly according to thecodes.