Add a builder to SimplifyContext to avoid allocating default values#21092
Add a builder to SimplifyContext to avoid allocating default values#21092AdamGS wants to merge 4 commits intoapache:mainfrom
SimplifyContext to avoid allocating default values#21092Conversation
Signed-off-by: Adam Gutglick <adamgsal@gmail.com>
|
Run benchmark sql_planner |
|
🤖 Criterion benchmark running (GKE) | trigger |
|
Benchmark for this request failed. Last 20 lines of output: Click to expand |
|
@Dandandan should I rebase this on top of #21084? |
alamb
left a comment
There was a problem hiding this comment.
I think this is an API improvement even if it doesn't measurably improve the performance -- thank you @AdamGS
One thing I thought of that might be less invasive (as in require less code changes) would be to use a single global lazy lock for default config options. Something like
/// Global default configuration options
static DEFAULT_CONFIG: LazyLock<Arc<ConfigOptions>> = LazyLock::new(|| Arc::new(ConfigOptions::new()));
impl ConfigOptions {
/// Creates a new [`ConfigOptions`] with default values
pub fn new() -> Self {
Self::default()
}
/// Return a reference to the default configuration options
pub fn default_arc() -> Arc<Self> {
Arc::clone(&DEFAULT_CONFIG)
}Let me see if I can make a PR that does this
| let state = self.state.read(); | ||
| let context = SimplifyContext::default() | ||
| let context = SimplifyContext::builder() | ||
| .with_schema(Arc::clone(prepared.plan.schema())) |
There was a problem hiding this comment.
I recommend we also deprecate SimplifyContext::with... methods (can do it as a follow on PR) and direct people to use the builder in their own code.
There was a problem hiding this comment.
That makes perfect sense, I'll add it in this one
I made I have queued up some benchmark runs (sql_planner) for these branches -- let's see what they say (should be done in an hour or two) |
|
What should the edit: FWIW - I'll happily backport this to 53.1.0 if necessary |
Signed-off-by: Adam Gutglick <adamgsal@gmail.com>
0de841f to
8d0c0d5
Compare
54 for now (and we can change it to 53 if we choose to backport) |
Signed-off-by: Adam Gutglick <adamgsal@gmail.com>
|
🤖 |
|
🤖: Benchmark completed Details
|
Woah, is this right? |
|
run benchmarks |
|
🤖 Benchmark completed (GKE) | trigger Details
Resource Usagetpch — base (merge-base)
tpch — branch
|
|
🤖 Benchmark completed (GKE) | trigger Details
Resource Usagetpcds — base (merge-base)
tpcds — branch
|
|
🤖 Benchmark completed (GKE) | trigger Details
Resource Usageclickbench_partitioned — base (merge-base)
clickbench_partitioned — branch
|
I bet it is less of a win after #21084 is merged. I'll update and rerun |
|
🤖 |
|
🤖: Benchmark completed Details
|
|
Seems like still a small win |
|
🤖 |
|
🤖: Benchmark completed Details
|
Which issue does this PR close?
Rationale for this change
This is a follow up to #21084, where @blaginin realized that allocating
ConfigOptionshas this surprising side effect. Reading through how its used I realized that on mode "real" code paths (and in many tests), DataFusion ends up allocating the default values ofSimplifyContextjust to immediately drop them and override them with pre-existing clone-able data.What changes are included in this PR?
Adds a new type
SimplifyContextBuilderandSimplifyContext::builderAre these changes tested?
Includes a couple of tests to make sure the builder makes sense, in addition to many existing tests.
Are there any user-facing changes?
As noted above, new type and a new function on an existing type.