-
Notifications
You must be signed in to change notification settings - Fork 81
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
Introduce Blink-To-Append-Only Memoization and Apply to TableLoggers #4880
Introduce Blink-To-Append-Only Memoization and Apply to TableLoggers #4880
Conversation
} | ||
} | ||
final QueryTable coalesced = (QueryTable) blinkTable.coalesce(); | ||
|
||
private static Table internalBlinkToAppendOnly(final Table blinkTable, long sizeLimit) { | ||
return QueryPerformanceRecorder.withNugget("blinkToAppendOnly", () -> { | ||
if (!isBlink(blinkTable)) { | ||
if (!isBlink(coalesced)) { |
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 see the order has changed here - coalescing first then checking blink. Does it make more sense to keep the check first?
More generally, are we really using coalesce() b/c we need to make sure manage livenessscope stack stuff? If so, are we maybe abusing coalesce in this context b/c we already know a blinktable is coalesced? (And maybe, we should have a more appropriate method on Table for this situation?)
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.
- It would not be inappropriate to do the check before coalescing.
- It's better to do the coalesce inside of the
withUpdateGraph()
, although that should be managed internally anyway. - The
coalesce()
is very much "belt and suspenders" hypothetical correctness in this case, as there are no uncoalesced blink tables in use. - What more appropriate method do you have in mind?
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.
Good catch. That is my mistake. I needed the QueryTable to invoke getResult
and I got the order wrong.
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/MemoizedOperationKey.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/MemoizedOperationKey.java
Outdated
Show resolved
Hide resolved
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.
Mostly looking good. I wish you had separated out some of the refactoring to its own commit.
@@ -116,7 +116,7 @@ default boolean snapshotNeeded() { | |||
*/ | |||
class Result<T extends DynamicNode & NotificationStepReceiver> { | |||
public final T resultNode; | |||
public final TableUpdateListener resultListener; // may be null if parent is non-ticking | |||
public final TableUpdateListener resultListener; // may be null if parent or result are non-refreshing |
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.
When do we anticipate a non-refreshing result from a refreshing parent? snapshot()
. Any others?
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 see what you had in mind. I think this comment should be revised, but I can accept that there's a case for no listener.
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.
In this case .. the append-only table could hit its size limit during initialization. Maybe this is an over optimization, but it does allow the result to be static. I can't think of anything other than a snapshot.
engine/table/src/main/java/io/deephaven/engine/table/impl/OperationSnapshotControl.java
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/updategraph/impl/PeriodicUpdateGraph.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Ryan Caudy <[email protected]>
469f8b7
to
6b0a91d
Compare
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.
.
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
public static final Object DEFAULT_MEMO_KEY = new Object() { | ||
@Override | ||
public String toString() { | ||
return "DEFAULT_MEMOIZATION_KEY"; | ||
} | ||
}; |
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.
Could just be
new String("DEFAULT_MEMOIZATION_KEY");
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 a fan of how it's setup here w/ Object; even though unlikely, a string-based memo-key is "public" and the user can just use the same string.
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 think that's an argument for using object identity when comparing memo keys. Also, why is it bad if the user really wants to explicitly use our default memo key? It's public here, for some reason, although I'd think it could be private.
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.
Oh, I see it's explicitly public. That said, I still think it makes sense as object. (Only way to get default memo is to explicitly use this key.)
I don't think we'd want to use object identity for all memo, otherwise it wouldn't be obvious how one achieves memo over API today.
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.
OK. I'm convinced enough. We stick to Object equality, keep this default as an Object so it will rely on reference equality, and maybe make it private (but I'm ambivalent about that).
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Outdated
Show resolved
Hide resolved
engine/table/src/main/java/io/deephaven/engine/table/impl/BlinkTableTools.java
Show resolved
Hide resolved
Labels indicate documentation is required. Issues for documentation have been opened: How-to: https://github.com/deephaven/deephaven.io/issues/3488 |
The primary purpose is to make
PerformanceQueries
work as intended (best-effort w.r.t. memory usage when not in use) according to existing documentation.