- 23 Jun, 2016 1 commit
-
-
tielei authored
-
- 20 Jun, 2016 1 commit
-
-
Yossi Gottlieb authored
-
- 03 Jun, 2016 1 commit
-
-
antirez authored
-
- 30 May, 2016 1 commit
-
-
ideal authored
-
- 01 Oct, 2015 5 commits
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 5 commits
- 14 Jul, 2015 1 commit
-
-
Oran Agra authored
-
- 11 Mar, 2015 1 commit
-
-
antirez authored
Still many things to convert inside config.c in the next commits. Some const safety in String objects creation and addReply() family functions.
-
- 27 Feb, 2015 1 commit
-
-
antirez authored
Should be much faster, and regardless, the code is more obvious now compared to generating a string just to get the return value of the ll2stirng() function.
-
- 02 Jan, 2015 1 commit
-
-
Matt Stancliff authored
This replaces individual ziplist vs. linkedlist representations for Redis list operations. Big thanks for all the reviews and feedback from everybody in https://github.com/antirez/redis/pull/2143
-
- 03 Dec, 2014 1 commit
-
-
antirez authored
-
- 02 Dec, 2014 1 commit
-
-
antirez authored
Ref: issue #2175
-
- 18 Jul, 2014 1 commit
-
-
antirez authored
In order to make sure every object has its own private LRU counter, when maxmemory is enabled tryObjectEncoding() does not use the pool of shared integers. However when the policy is not LRU-based, it does not make sense to do so, and it is much better to save memory using shared integers.
-
- 11 Jul, 2014 1 commit
-
-
michael-grunder authored
Previously, the command definition for the OBJECT command specified a minimum of two args (and that it was variadic), which meant that if you sent this: OBJECT foo When cluster was enabled, it would result in an assertion/SEGFAULT when Redis was attempting to extract keys. It appears that OBJECT is not variadic, and only ever takes 3 args. https://gist.github.com/michael-grunder/25960ce1508396d0d36a
-
- 12 May, 2014 1 commit
-
-
Matt Stancliff authored
Renaming strtold to strtod then casting the result is the standard way of dealing with no strtold in Cygwin.
-
- 07 May, 2014 1 commit
-
-
antirez authored
The new value is the limit for the robj + SDS header + string + null-term to stay inside the 64 bytes Jemalloc arena in 64 bits systems.
-
- 04 Apr, 2014 1 commit
-
-
antirez authored
We also avoid to re-create an object that is already in EMBSTR encoding.
-
- 30 Mar, 2014 1 commit
-
-
antirez authored
All the Redis functions that need to modify the string value of a key in a destructive way (APPEND, SETBIT, SETRANGE, ...) require to make the object unshared (if refcount > 1) and encoded in raw format (if encoding is not already REDIS_ENCODING_RAW). This was cut & pasted many times in multiple places of the code. This commit puts the small logic needed into a function called dbUnshareStringValue().
-
- 24 Mar, 2014 1 commit
-
-
Matt Stancliff authored
lookupKey() uses LRU_CLOCK(), so it seems object creation should use LRU_CLOCK() too.
-
- 21 Mar, 2014 1 commit
-
-
antirez authored
Thanks to Matt Stancliff for noticing this error. It was in the original code but somehow I managed to remove the change from the commit...
-
- 20 Mar, 2014 3 commits
-
-
antirez authored
estimateObjectIdleTime() returns a value in milliseconds now, so we need to scale the output of OBJECT IDLETIME to seconds.
-
antirez authored
For testing purposes it is handy to have a very high resolution of the LRU clock, so that it is possible to experiment with scripts running in just a few seconds how the eviction algorithms works. This commit allows Redis to use the cached LRU clock, or a value computed on demand, depending on the resolution. So normally we have the good performance of a precomputed value, and a clock that wraps in many days using the normal resolution, but if needed, changing a define will switch behavior to an high resolution LRU clock.
-
antirez authored
-
- 05 Dec, 2013 1 commit
-
-
antirez authored
-
- 27 Aug, 2013 3 commits
-
-
antirez authored
We are sure the string is large, since when the sds optimization branch is entered it means that it was not possible to encode it as EMBSTR for size concerns.
-
antirez authored
When no encoding is possible, at least try to reallocate the sds string with one that does not waste memory (with free space at the end of the buffer) when the string is large enough.
-
antirez authored
We are sure that a string that is longer than 21 chars cannot be represented by a 64 bit signed integer, as -(2^64) is 21 chars: strlen(-18446744073709551616) => 21
-
- 28 Jul, 2013 1 commit
-
-
antirez authored
Thanks to @run and @badboy for spotting this. Triva: clang was not able to provide me a warning about that when compiling. This closes #1024 and #1207, committing the change myself as the pull requests no longer apply cleanly after other changes to the same function.
-
- 22 Jul, 2013 1 commit
-
-
antirez authored
Previously two string encodings were used for string objects: 1) REDIS_ENCODING_RAW: a string object with obj->ptr pointing to an sds stirng. 2) REDIS_ENCODING_INT: a string object where the obj->ptr void pointer is casted to a long. This commit introduces a experimental new encoding called REDIS_ENCODING_EMBSTR that implements an object represented by an sds string that is not modifiable but allocated in the same memory chunk as the robj structure itself. The chunk looks like the following: +--------------+-----------+------------+--------+----+ | robj data... | robj->ptr | sds header | string | \0 | +--------------+-----+-----+------------+--------+----+ | ^ +-----------------------+ The robj->ptr points to the contiguous sds string data, so the object can be manipulated with the same functions used to manipulate plan string objects, however we need just on malloc and one free in order to allocate or release this kind of objects. Moreover it has better cache locality. This new allocation strategy should benefit both the memory usage and the performances. A performance gain between 60 and 70% was observed during micro-benchmarks, however there is more work to do to evaluate the performance impact and the memory usage behavior.
-
- 16 Jul, 2013 1 commit
-
-
antirez authored
This fixes issue #1194, that contains many details. However in short, it was possible for ZADD to not accept as score values that was however possible to obtain with multiple calls to ZINCRBY, like in the following example: redis 127.0.0.1:6379> zadd k 2.5e-308 m (integer) 1 redis 127.0.0.1:6379> zincrby k -2.4e-308 m "9.9999999999999694e-310" redis 127.0.0.1:6379> zscore k m "9.9999999999999694e-310" redis 127.0.0.1:6379> zadd k 9.9999999999999694e-310 m1 (error) ERR value is not a valid float The problem was due to strtod() returning ERANGE in the following case specified by POSIX: "If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE].". Now instead the returned value is accepted even when ERANGE is returned as long as the return value of the function is not negative or positive HUGE_VAL or zero.
-
- 12 Jul, 2013 1 commit
-
-
antirez authored
compareStringObject was not always giving the same result when comparing two exact strings, but encoded as integers or as sds strings, since it switched to strcmp() when at least one of the strings were not sds encoded. For instance the two strings "123" and "123\x00456", where the first string was integer encoded, would result into the old implementation of compareStringObject() to return 0 as if the strings were equal, while instead the second string is "greater" than the first in a binary comparison. The same compasion, but with "123" encoded as sds string, would instead return a value < 0, as it is correct. It is not impossible that the above caused some obscure bug, since the comparison was not always deterministic, and compareStringObject() is used in the implementation of skiplists, hash tables, and so forth. At the same time, collateStringObject() was introduced by this commit, so that can be used by SORT command to return sorted strings usign collation instead of binary comparison. See next commit.
-