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

Implement Internal Cache #4964

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

atmaxinger
Copy link
Contributor

Basics

  • Short descriptions of your changes are in the release notes
    (added as entry in doc/news/_preparation_next_release.md which contains _(my name)_)
    Please always add them to the release notes.
  • Details of what you changed are in commit messages
    (first line should have module: short statement syntax)
  • References to issues, e.g. close #X, are in the commit messages.
  • The buildservers are happy. If not, fix in this order:
    • add a line in doc/news/_preparation_next_release.md
    • reformat the code with scripts/dev/reformat-all
    • make all unit tests pass
    • fix all memleaks
    • fix the CI itself (or rebase if already fixed)
  • The PR is rebased with current master.

Checklist

  • I added unit tests for my code
  • I fully described what my PR does in the documentation
    (not in the PR description)
  • I fixed all affected documentation (see Documentation Guidelines)
  • I fixed all affected decisions (see Decision Process)
  • I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
  • I updated all meta data (e.g. README.md of plugins and METADATA.ini)
  • I mentioned every code not directly written by me in reuse syntax

Review

Labels

  • Add the "work in progress" label if you do not want the PR to be reviewed yet.
  • Add the "ready to merge" label if everything is done and no further pushes are planned by you.

Comment on lines +1983 to +1984
ksAppend (keysForSpec, dataKs);
ksAppend (keysForSpec, fromInternalCache);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ksAppend (keysForSpec, dataKs);
ksAppend (keysForSpec, fromInternalCache);
ksAppend (keysForSpec, fromInternalCache);
ksAppend (keysForSpec, dataKs);

Isn't this the wrong way around? In Step 18, fromInternalCache is appended first

@@ -2055,6 +2084,7 @@ int kdbGet (KDB * handle, KeySet * ks, Key * parentKey)

ksDel (backends);
ksDel (allBackends);
if (fromInternalCache) ksDel (fromInternalCache);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (fromInternalCache) ksDel (fromInternalCache);
ksDel (fromInternalCache);

ksDel (NULL) is a no-op

Comment on lines +2510 to +2518
below = ksBelow (handle->allKeys, backendKey);
ksDel (ksCut (below, initialParent));

KeySet * bBackend = ksBelow (ks, backendKey);
KeySet * bParent = ksBelow (bBackend, initialParent);
ksAppend (below, bParent);

ksDel (bParent);
ksDel (bBackend);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might be easier with ksFindHierarchy and a loop of ksAppendKey and performance-wise it makes no difference since ksAppend is also a loop of ksAppendKey right now (but you avoid allocating all these temporary KeySets).

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

Successfully merging this pull request may close these issues.

Multiple kdbGet for the same parent key will lead to no returned keys.
3 participants