- 09 Apr, 2019 1 commit
-
-
yongman authored
-
- 09 Jan, 2019 1 commit
-
-
antirez authored
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 23 Feb, 2017 2 commits
-
-
Salvatore Sanfilippo authored
-
Salvatore Sanfilippo authored
-
- 19 Feb, 2017 1 commit
-
-
Salvatore Sanfilippo authored
GCC will produce certain unaligned multi load-store instructions that will be trapped by the Linux kernel since ARM v6 cannot handle them with unaligned addresses. Better to use the slower but safer implementation instead of generating the exception which should be anyway very slow.
-
- 21 Oct, 2016 1 commit
-
-
sunhe authored
-
- 16 Jun, 2016 1 commit
-
-
antirez authored
Comment format fixed + local var modified from camel case to underscore separators as Redis code base normally does (camel case is mostly used for global symbols like structure names, function names, global vars, ...).
-
- 15 Jun, 2016 2 commits
- 05 Jun, 2016 1 commit
-
-
Pierre Chapuis authored
-
- 31 May, 2016 1 commit
-
-
antirez authored
Probably there is no compiler that will actaully break the code or raise a signal for unsigned -> signed overflowing conversion, still it was apparently possible to write it in a more correct way. All tests passing.
-
- 30 May, 2016 1 commit
-
-
wenduo authored
-
- 24 May, 2016 2 commits
-
-
oranagra authored
optimization: lookup key only once, and grow at once to the max need fixes #3259 and #3221, and also an early return if wrongtype is discovered by SET
-
- 18 May, 2016 1 commit
-
-
antirez authored
-
- 10 May, 2016 1 commit
-
-
oranagra authored
-
- 02 Mar, 2016 3 commits
- 29 Feb, 2016 1 commit
-
-
antirez authored
-
- 26 Feb, 2016 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
The new bitfield command is an extension to the Redis bit operations, where not just single bit operations are performed, but the array of bits composing a string, can be addressed at random, not aligned offsets, with any width unsigned and signed integers like u8, s5, u10 (up to 64 bit signed integers and 63 bit unsigned integers). The BITFIELD command supports subcommands that can SET, GET, or INCRBY those arbitrary bit counters, with multiple overflow semantics. Trivial and credits: A similar command was imagined a few times in the past, but for some reason looked a bit far fetched or not well specified. Finally the command was proposed again in a clear form by Yoav Steinberg from Redis Labs, that proposed a set of commands on arbitrary sized integers stored at bit offsets. Starting from this proposal I wrote an initial specification of a single command with sub-commands similar to what Yoav envisioned, using short names for types definitions, and adding control on the overflow. This commit is the resulting implementation. Examples: BITFIELD mykey OVERFLOW wrap INCRBY i2 10 -1 GET i2 10
-
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 4 commits
- 11 Dec, 2014 1 commit
-
-
Matt Stancliff authored
Previously the string was created empty then re-sized to fit the offset, but sds resize causes the sds to over-allocate by at least 1 MB (which is a lot when you are operating at bit-level access). This also improves the speed of initial sets by 2% to 6% based on quick testing. Patch logic provided by @oranagra Fixes #1918
-
- 03 Dec, 2014 1 commit
-
-
Sun He authored
-
- 02 Dec, 2014 1 commit
-
-
Sun He authored
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 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().
-
- 27 Feb, 2014 4 commits
-
-
antirez authored
-
antirez authored
With the new behavior it is possible to specify just the start in the range (the end will be assumed to be the first byte), or it is possible to specify both start and end. This is useful to change the behavior of the command when looking for zeros inside a string. 1) If the user specifies both start and end, and no 0 is found inside the range, the command returns -1. 2) If instead no range is specified, or just the start is given, even if in the actual string no 0 bit is found, the command returns the first bit on the right after the end of the string. So for example if the string stored at key foo is "\xff\xff": BITPOS foo (returns 16) BITPOS foo 0 -1 (returns -1) BITPOS foo 0 (returns 16) The idea is that when no end is given the user is just looking for the first bit that is zero and can be set to 1 with SETBIT, as it is "available". Instead when a specific range is given, we just look for a zero within the boundaries of the range.
-
antirez authored
It appears to work but more stress testing, and both unit tests and fuzzy testing, is needed in order to ensure the implementation is sane.
-
antirez authored
-
- 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.
-
- 26 Jun, 2013 1 commit
-
-
antirez authored
-