Skip to content
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

Investigate the value of 0-Copy retrival API #121

Closed
AlgorithmsAreCool opened this issue Jun 18, 2020 · 1 comment
Closed

Investigate the value of 0-Copy retrival API #121

AlgorithmsAreCool opened this issue Jun 18, 2020 · 1 comment

Comments

@AlgorithmsAreCool
Copy link
Collaborator

Issue #116 offered 'option 3' as a way to potentially allow faster access to large keys by avoiding the implicit copy of the other Get methods.

Proposed API Shape

public class Transaction
{
  public bool TryGet(LightningDatabase db, ReadOnlySpan<byte> key, TArg arg, ReadOnlySpanAction<byte, TArg> inspector);
}

Discussion

Unfortunately, the proposed API shape is tricky to understand and while generally safe, is even trickier to use in a way that offers optimal performance. To use correctly you need to provide a delegate that, at minimum, follows these rules:

  • [PERF] Ensure your passed delegate isn't being re-allocated each call
  • [PERF] Ensure your delegate doesn't block or waste time. This can delay a pending write transaction.
  • [SAFETY] Ensure you do not try to store the Span itself outside of the scope of the transaction.

Therefore, someone (probably me) should investigate and measure the performance semantics of this API shape.

@CoreyKaylor
Copy link
Owner

Probably not needed anymore after #125

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants