- 11 Jul, 2017 1 commit
-
-
antirez authored
Close #3766.
-
- 23 Feb, 2017 1 commit
-
-
Salvatore Sanfilippo authored
-
- 19 Feb, 2017 2 commits
-
-
Salvatore Sanfilippo authored
However note that in architectures supporting 64 bit unaligned accesses memcpy(...,...,8) is likely translated to a simple word memory movement anyway.
-
Salvatore Sanfilippo authored
-
- 16 Dec, 2016 3 commits
-
-
antirez authored
The new algorithm provides the same speed with a smaller error for cardinalities in the range 0-100k. Before switching, the new and old algorithm behavior was studied in details in the context of issue #3677. You can find a few graphs and motivations there.
-
antirez authored
Otherwise for small cardinalities the algorithm will output something like, for example, 4.99 for a candinality of 5, that will be converted to 4 producing a huge error.
-
Harish Murthy authored
Config option to use LogLog-Beta Algorithm for Cardinality
-
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 5 commits
- 10 Dec, 2014 1 commit
-
-
antirez authored
Slaves key expire is orchestrated by the master. Sometimes the master will send the synthesized DEL to expire keys on the slave with a non trivial delay (when the key is not accessed, only the incremental expiry algorithm will expire it in background). During that time, a key is logically expired, but slaves still return the key if you GET (or whatever) it. This is a bad behavior. However we can't simply trust the slave view of the key, since we need the master to be able to send write commands to update the slave data set, and DELs should only happen when the key is expired in the master in order to ensure consistency. However 99.99% of the issues with this behavior is when a client which is not a master sends a read only command. In this case we are safe and can consider the key as non existing. This commit does a few changes in order to make this sane: 1. lookupKeyRead() is modified in order to return NULL if the above conditions are met. 2. Calls to lookupKeyRead() in commands actually writing to the data set are repliaced with calls to lookupKeyWrite(). There are redundand checks, so for example, if in "2" something was overlooked, we should be still safe, since anyway, when the master writes the behavior is to don't care about what expireIfneeded() returns. This commit is related to #1768, #1770, #2131.
-
- 02 Dec, 2014 1 commit
-
-
antirez authored
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 23 Jul, 2014 1 commit
-
-
antirez authored
This is just a quickfix, for the nature of the test the right way to fix it is to average the error of N runs, since otherwise it is always possible to get a false positive with a bad run, or to minimize too much this possibility we may end testing with too much "large" error ranges.
-
- 18 May, 2014 1 commit
-
-
Mike Trinkala authored
Set the MSB as documented.
-
- 17 Apr, 2014 4 commits
-
-
antirez authored
The internal HLL raw encoding used by PFCOUNT when merging multiple keys is aligned to 8 bits (1 byte per register) so we can exploit this to improve performances by processing multiple bytes per iteration. In benchmarks the new code was several times faster with HLLs with many registers set to zero, while no slowdown was observed with populated HLLs.
-
antirez authored
When the register is set to zero, we need to add 2^-0 to E, which is 1, but it is faster to just add 'ez' at the end, which is the number of registers set to zero, a value we need to compute anyway.
-
antirez authored
-
antirez authored
-
- 16 Apr, 2014 2 commits
- 15 Apr, 2014 2 commits
- 14 Apr, 2014 14 commits
-
-
antirez authored
-
antirez authored
After running a few benchmarks, 3000 looks like a reasonable value to keep HLLs with a few thousand elements small while the CPU cost is still not huge. This covers all the cases where the dense representation would use N orders of magnitude more space, like in the case of many HLLs with carinality of a few tens or hundreds. It is not impossible that in the future this gets user configurable, however it is easy to pick an unreasoable value just looking at savings in the space dimension without checking what happens in the time dimension.
-
antirez authored
-
antirez authored
-
antirez authored
Even if it is a debugging command, make sure that when it forces a change in encoding, the command is propagated.
-
antirez authored
If we converted to dense, a register must be updated in the dense representation.
-
antirez authored
Mostly by reordering opcodes check conditional by frequency of opcodes in larger sparse-encoded HLLs.
-
antirez authored
-
antirez authored
Bottleneck found profiling. Big run time improvement found when testing after the change.
-
antirez authored
-
antirez authored
As more values are added splitting ZERO or XZERO opcodes, try to merge adjacent VAL opcodes if they have the same value.
-
antirez authored
Now the macros will work with arguments such as "ptr+1".
-
antirez authored
-
antirez authored
Bulk length for registers was emitted too early, so if there was a bug the reply looked like a long array with just one element, blocking the client as result.
-