- 19 Oct, 2018 1 commit
-
- 14 Sep, 2018 1 commit
-
-
antirez authored
-
- 12 Sep, 2018 1 commit
-
-
antirez authored
-
- 04 Jul, 2018 1 commit
-
-
antirez authored
-
- 25 May, 2018 2 commits
-
-
zhaozhao.zz authored
-
antirez authored
-
- 23 Apr, 2018 2 commits
- 10 Apr, 2018 1 commit
-
-
artix authored
-
- 15 Mar, 2018 1 commit
-
-
charsyam authored
-
- 22 Feb, 2018 1 commit
-
-
artix authored
-
- 01 Dec, 2017 1 commit
-
-
antirez authored
-
- 10 Jul, 2017 1 commit
-
-
antirez authored
-
- 05 Jul, 2017 1 commit
-
-
spinlock authored
-
- 03 Jul, 2017 1 commit
-
-
Jun He authored
Change-Id: I9801239c98cb7362ed07e8b9ec2ba7e45749dba7 Signed-off-by:
Jun He <jun.he@arm.com>
-
- 26 Jun, 2017 1 commit
-
-
antirez authored
-
- 10 May, 2017 1 commit
-
-
antirez authored
This avoids Helgrind complaining, but we are actually not using atomicGet() to get the unixtime value for now: too many places where it is used and given tha time_t is word-sized it should be safe in all the archs we support as it is. On the other hand, Helgrind, when Redis is compiled with "make helgrind" in order to force the __sync macros, will detect the write in updateCachedTime() as a read (because atomic functions are used) and will not complain about races. This commit also includes minor refactoring of mutex initializations and a "helgrind" target in the Makefile.
-
- 17 Apr, 2017 1 commit
-
-
Jan-Erik Rediger authored
Fixes #3944
-
- 27 Mar, 2017 1 commit
-
-
antirez authored
-
- 23 Feb, 2017 1 commit
-
-
Salvatore Sanfilippo authored
-
- 20 Feb, 2017 2 commits
-
-
antirez authored
-
antirez authored
This change attempts to switch to an hash function which mitigates the effects of the HashDoS attack (denial of service attack trying to force data structures to worst case behavior) while at the same time providing Redis with an hash function that does not expect the input data to be word aligned, a condition no longer true now that sds.c strings have a varialbe length header. Note that it is possible sometimes that even using an hash function for which collisions cannot be generated without knowing the seed, special implementation details or the exposure of the seed in an indirect way (for example the ability to add elements to a Set and check the return in which Redis returns them with SMEMBERS) may make the attacker's life simpler in the process of trying to guess the correct seed, however the next step would be to switch to a log(N) data structure when too many items in a single bucket are detected: this seems like an overkill in the case of Redis. SPEED REGRESION TESTS: In order to verify that switching from MurmurHash to SipHash had no impact on speed, a set of benchmarks involving fast insertion of 5 million of keys were performed. The result shows Redis with SipHash in high pipelining conditions to be about 4% slower compared to using the previous hash function. However this could partially be related to the fact that the current implementation does not attempt to hash whole words at a time but reads single bytes, in order to have an output which is endian-netural and at the same time working on systems where unaligned memory accesses are a problem. Further X86 specific optimizations should be tested, the function may easily get at the same level of MurMurHash2 if a few optimizations are performed.
-
- 19 Feb, 2017 2 commits
-
-
Salvatore Sanfilippo authored
I'm not sure how much test Jemalloc gets on ARM, moreover compiling Redis with Jemalloc support in not very powerful devices, like most ARMs people will build Redis on, is extremely slow. It is possible to enable Jemalloc build anyway if needed by using "make MALLOC=jemalloc".
-
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.
-
- 30 Dec, 2016 1 commit
-
-
oranagra authored
-
- 19 Sep, 2016 1 commit
-
-
antirez authored
-
- 07 Sep, 2016 1 commit
-
-
antirez authored
-
- 06 Jul, 2016 4 commits
-
-
antirez authored
They were under /deps since they originate from a different source tree, however at this point they are very modified and we took ownership of both the files making changes, fixing bugs, so there is no upgrade path from the original code tree. Given that, better to move the code under /src with proper dependencies and with a more simpler editing experience.
-
antirez authored
-
antirez authored
-
antirez authored
Normally we used to update it from time to time. Too fragile... better to generate dependencies at every run and delete them on 'make clean'.
-
- 14 Jun, 2016 1 commit
-
-
zach shipko authored
-
- 18 May, 2016 1 commit
-
-
antirez authored
Compiling Redis worked as a side effect of jemalloc target specifying -ldl as needed linker options, otherwise it is not provided during linking and dlopen() API will remain unresolved symbols.
-
- 10 May, 2016 1 commit
-
-
antirez authored
-
- 01 Oct, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 1 commit
-
-
antirez authored
-
- 14 Jul, 2015 2 commits
- 23 Jun, 2015 1 commit
-
-
antirez authored
This commit simplifies the implementation in a few ways: 1. zsetScore implementation improved a bit and moved into t_zset.c where is now also used to implement the ZSCORE command. 2. Range extraction from the sorted set remains a separated implementation from the one in t_zset.c, but was hyper-specialized in order to avoid accumulating results into a list and remove the ones outside the radius. 3. A new type is introduced: geoArray, which can accumulate geoPoint structures in a vector with power of two expansion policy. This is useful since we have to call qsort() against it before returning the result to the user. 4. As a result of 1, 2, 3, the two files zset.c and zset.h are now removed, including the function to merge two lists (now handled with functions that can add elements to existing geoArray arrays) and the machinery used in order to pass zset results. 5. geoPoint structure simplified because of the general code structure simplification, so we no longer need to take references to objects. 6. Not counting the JSON removal the refactoring removes 200 lines of code for the same functionalities, with a simpler to read implementation. 7. GEORADIUS is now 2.5 times faster testing with 10k elements and a radius resulting in 124 elements returned. However this is mostly a side effect of the refactoring and simplification. More speed gains can be achieved by trying to optimize the code.
-
- 22 Jun, 2015 1 commit
-
-
antirez authored
For some reason the Geo PR included disabling the fact that Redis is compiled with optimizations. Apparently it was just @mattsta attempt to speedup the modify-compile-test iteration and there are no other reasons.
-