- 02 Jan, 2017 1 commit
-
-
oranagra authored
-
- 30 Dec, 2016 1 commit
-
-
oranagra authored
-
- 20 Sep, 2016 1 commit
-
-
antirez authored
Recently we moved the "return ASAP" condition for the Delete() function from checking .size to checking .used, which is smarter, however while testing the first table alone always works to ensure the dict is totally emtpy, when we test the .size field, testing .used requires testing both T0 and T1, since a rehashing could be in progress.
-
- 14 Sep, 2016 3 commits
-
-
antirez authored
What they say about "naming things" in programming?
-
antirez authored
Optimizations suggested and originally implemented by @oranagra. Re-applied by @antirez using the modified API.
-
oranagra authored
Notes by @antirez: This patch was picked from a larger commit by Oran and adapted to change the API a bit. The basic idea is to avoid double lookups when there is to use the value of the deleted entry. BEFORE: entry = dictFind( ... ); /* 1st lookup. */ /* Do somethjing with the entry. */ dictDelete(...); /* 2nd lookup. */ AFTER: entry = dictUnlink( ... ); /* 1st lookup. */ /* Do somethjing with the entry. */ dictFreeUnlinkedEntry(entry); /* No lookups!. */
-
- 12 Sep, 2016 1 commit
-
-
oranagra authored
(Change cherry-picked and modified by @antirez from a larger commit provided by @oranagra in PR #3223).
-
- 07 Sep, 2016 6 commits
- 25 Apr, 2016 1 commit
-
-
Oran Agra authored
-
- 01 Oct, 2015 1 commit
-
-
antirez authored
-
- 14 Jul, 2015 1 commit
-
-
antirez authored
The command reports information about the hash table internal state representing the specified database ID. This can be used in order to investigate rehashings, memory usage issues and for other debugging purposes.
-
- 27 Mar, 2015 2 commits
-
-
antirez authored
No semantical changes since to make dict.c truly able to scale over the 32 bit table size limit, the hash function shoulds and other internals related to hash function output should be 64 bit ready.
-
antirez authored
rehashidx is always positive in the two code paths, since the only negative value it could have is -1 when there is no rehashing in progress, and the condition is explicitly checked.
-
- 11 Feb, 2015 11 commits
-
-
antirez authored
The old version of SPOP with "count" argument used an API call of dict.c which was actually designed for a different goal, and was not capable of good distribution. We follow a different three-cases approach optimized for different ratiion between sets and requested number of elements. The implementation is simpler and allowed the removal of a large amount of code.
-
antirez authored
Fixed by @oranagra, thank you.
-
antirez authored
-
antirez authored
Avoid code repetition introduced with PR #2367, also fixes the return value to always return 0 if there is nothing more to rehash.
-
Sun He authored
-
antirez authored
This is very similar to the optimization applied to dictGetRandomKeys, but applied to the single key variant. Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
antirez authored
We use the invariant that the original table ht[0] is never populated up to the index before the current rehashing index. Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
- 23 Jan, 2015 1 commit
-
-
antirez authored
-
- 29 Sep, 2014 2 commits
-
-
Matt Stancliff authored
Some language in the comment was difficult to understand, so this commit: clarifies wording, removes unnecessary words, and relocates some dependent clauses closer to what they actually describe. I also tried to break up longer chains of thought (if X, then Y, and Q, and also F, so obviously M) into more manageable chunks for ease of understanding.
-
Michael Parker authored
Closes #1351
-
- 26 Aug, 2014 2 commits
- 18 Aug, 2014 1 commit
-
-
Cong Ding authored
Closes #878
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 20 Mar, 2014 1 commit
-
-
antirez authored
This new function is useful to get a number of random entries from an hash table when we just need to do some sampling without particularly good distribution. It just jumps at a random place of the hash table and returns the first N items encountered by scanning linearly. The main usefulness of this function is to speedup Redis internal sampling of the key space, for example for key eviction or expiry.
-
- 04 Mar, 2014 2 commits
-
-
zhanghailei authored
-
zhanghailei authored
-
- 10 Dec, 2013 1 commit
-
-
antirez authored
Redis hash table implementation has many non-blocking features like incremental rehashing, however while deleting a large hash table there was no way to have a callback called to do some incremental work. This commit adds this support, as an optiona callback argument to dictEmpty() that is currently called at a fixed interval (one time every 65k deletions).
-