-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
More string format removals #15316
More string format removals #15316
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -243,7 +243,9 @@ public Plan plan(Analysis analysis, Stage stage, boolean collectPlanStatistics) | |
if (stage.ordinal() >= OPTIMIZED.ordinal()) { | ||
for (PlanOptimizer optimizer : planOptimizers) { | ||
root = optimizer.optimize(root, session, symbolAllocator.getTypes(), symbolAllocator, idAllocator, warningCollector, tableStatsProvider); | ||
requireNonNull(root, format("%s returned a null plan", optimizer.getClass().getName())); | ||
if (root == null) { | ||
throw new NullPointerException(optimizer.getClass().getName() + " returned a null plan"); | ||
} | ||
Comment on lines
+246
to
+248
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I doubt this is significant enough to warrant making the code more verbose and harder to read. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While I'm sure that the performance cost isn't massive, this is called inside of the loop for each optimizer. On option would be to switch from There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. True, but there are only a handful of optimizers. Also, they do way more complicated things, so this is going to be a drop in the bucket. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does lambda capture matter here? I suspect this would be optimized away by inlining. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It won't matter as long as the JIT does actually inline the |
||
|
||
if (LOG.isDebugEnabled()) { | ||
LOG.debug("%s:\n%s", optimizer.getClass().getName(), PlanPrinter.textLogicalPlan( | ||
|
@@ -542,9 +544,7 @@ private RelationPlan getInsertPlan( | |
|
||
private Expression createNullNotAllowedFailExpression(String columnName, Type type) | ||
{ | ||
return new Cast(failFunction(metadata, session, CONSTRAINT_VIOLATION, format( | ||
"NULL value not allowed for NOT NULL column: %s", | ||
columnName)), toSqlType(type)); | ||
return new Cast(failFunction(metadata, session, CONSTRAINT_VIOLATION, "NULL value not allowed for NOT NULL column: " + columnName), toSqlType(type)); | ||
} | ||
|
||
private static Function<Expression, Expression> failIfPredicateIsNotMet(Metadata metadata, Session session, ErrorCodeSupplier errorCode, String errorMessage) | ||
|
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.
These make the code less readable, IMO. Also, the code generation is not such a frequent operation that performance of concatenation vs String.format is a concern.
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'm not sure I agree about concatenation being less readable, but that's a matter of taste so for the sake of argument, let's assume that format is slightly more readable. Even so, I don't agree with the idea that we should prefer the less efficient implementation (in non-exceptional, non-debugging code paths) by default. I'm arguing the opposite: even when the codepath is not especially "hot", we should prefer the more efficient of the two approaches when the readability difference is small to try to avoid accumulating thousands of small hits to performance overall.
If you still disagree, then I'm happy to remove either/both of the two places you left PR feedback comments about (and any others you want to flag)- I just wanted to make the case that we should reconsider the practice of adding these avoidable performance costs and prefer concatenation over formatting in the general.
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'm sympathetic to the "accumulating thousands of small hits to performance" argument, but the question is if this has any measurable impact. Our general philosophy is to prefer readability, unless the performance impact matters. This is a slippery slope.
In this specific case, I'm not sure it's less readable. But this one seems worse:
Hopefully String Templates will allow both readability and performance.
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.
@electrum - Fair point on the other change, I've pushed a new revision that removes that particular change in
CursorProcessorCompiler
.