- 22 4月, 2014 2 次提交
- 18 4月, 2014 4 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
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.
-
- 17 4月, 2014 9 次提交
-
-
由 antirez 提交于
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 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Given that the code was written with a 2 years pause... something strange happened in the middle. So there was no function to free a lex range min/max objects, and in some places the range was passed by value.
-
- 16 4月, 2014 4 次提交
- 15 4月, 2014 3 次提交
- 14 4月, 2014 18 次提交
-
-
由 antirez 提交于
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 提交于
-
由 antirez 提交于
-
由 antirez 提交于
It is safer since it is able to have side effects.
-
由 antirez 提交于
Even if it is a debugging command, make sure that when it forces a change in encoding, the command is propagated.
-
由 antirez 提交于
If we converted to dense, a register must be updated in the dense representation.
-
由 antirez 提交于
Mostly by reordering opcodes check conditional by frequency of opcodes in larger sparse-encoded HLLs.
-
由 antirez 提交于
-
由 antirez 提交于
Bottleneck found profiling. Big run time improvement found when testing after the change.
-
由 antirez 提交于
-
由 antirez 提交于
As more values are added splitting ZERO or XZERO opcodes, try to merge adjacent VAL opcodes if they have the same value.
-
由 antirez 提交于
Now the macros will work with arguments such as "ptr+1".
-
由 antirez 提交于
-
由 antirez 提交于
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.
-
由 antirez 提交于
-
由 antirez 提交于
We want to promote if the total string size exceeds the resulting size after the upgrade.
-
由 antirez 提交于
The function checks if all the HLL_REGISTERS were processed during the convertion from sparse to dense encoding, returning REDIS_OK or REDIS_ERR to signal a corruption problem. A bug in PFDEBUG GETREG was fixed: when the object is converted to the dense representation we need to reassign the new pointer to the header structure pointer.
-
由 antirez 提交于
Provides a human readable description of the opcodes composing a run-length encoded HLL (sparse encoding). The command is only useful for debugging / development tasks.
-