- 15 Apr, 2014 1 commit
- 
- 
antirez authored
 
- 
- 14 Apr, 2014 19 commits
- 
- 
antirez authored
- 
antirez authoredAfter 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 authoredIt is safer since it is able to have side effects. 
- 
antirez authoredEven if it is a debugging command, make sure that when it forces a change in encoding, the command is propagated. 
- 
antirez authoredIf we converted to dense, a register must be updated in the dense representation. 
- 
antirez authoredMostly by reordering opcodes check conditional by frequency of opcodes in larger sparse-encoded HLLs. 
- 
antirez authored
- 
antirez authoredBottleneck found profiling. Big run time improvement found when testing after the change. 
- 
antirez authored
- 
antirez authoredAs more values are added splitting ZERO or XZERO opcodes, try to merge adjacent VAL opcodes if they have the same value. 
- 
antirez authoredNow the macros will work with arguments such as "ptr+1". 
- 
antirez authored
- 
antirez authoredBulk 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 authored
- 
antirez authoredWe want to promote if the total string size exceeds the resulting size after the upgrade. 
- 
antirez authoredThe 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 authoredProvides a human readable description of the opcodes composing a run-length encoded HLL (sparse encoding). The command is only useful for debugging / development tasks. 
 
- 
- 13 Apr, 2014 3 commits
- 12 Apr, 2014 10 commits
- 
- 
antirez authoredsdsIncrLen() must be called anyway even if we are replacing the last oppcode of the sparse representation. 
- 
antirez authored
- 
antirez authored
- 
antirez authored
- 
antirez authored
- 
antirez authoredTwo vars initialized to wrong values in createHLLObject(). 
- 
antirez authored
- 
antirez authoredThe function didn't considered the fact that each XZERO opcode is two bytes. 
- 
antirez authored
- 
antirez authored
 
- 
- 11 Apr, 2014 4 commits
- 
- 
antirez authoredCode never tested, but the basic layout is shaped in this commit. Also missing: 1) Sparse -> Dense conversion function. 2) New HLL object creation using the sparse representation. 3) Implementation of PFMERGE for the sparse representation. 
- 
antirez authored
- 
antirez authoredAlso dense representation access macro renamed accordingly. 
- 
antirez authoredMetadata are now placed at the start of the representation as an header. There is a proper structure to access the representation. Still work to do in order to truly abstract the implementation from the representation, commands still work assuming dense representation. 
 
- 
- 10 Apr, 2014 1 commit
- 
- 
antirez authoredAfter running a few simulations with different alternative encodings, it was found that the VAL opcode performs better using 5 bits for the value and 2 bits for the run length, at least for cardinalities in the range of interest. 
 
- 
- 09 Apr, 2014 1 commit
- 
- 
antirez authored
 
- 
- 07 Apr, 2014 1 commit
- 
- 
antirez authoredadjustOpenFilesLimit() and clusterUpdateSlotsWithConfig() that were assuming uint64_t is the same as unsigned long long, which is true probably for all the systems out there that we target, but still GCC emitted a warning since technically they are two different types. 
 
-