1. 28 Aug, 2020 1 commit
    • Jim Brunner's avatar
      Use H/W Monotonic clock and updates to AE (#7644) · c01e94a4
      Jim Brunner authored
      Update adds a general source for retrieving a monotonic time.
      In addition, AE has been updated to utilize the new monotonic
      clock for timer processing.
      
      This performance improvement is **not** enabled in a default build due to various H/W compatibility
      concerns, see README.md for details. It does however change the default use of gettimeofday with
      clock_gettime and somewhat improves performance.
      
      This update provides the following
      1. An interface for retrieving a monotonic clock. getMonotonicUs returns a uint64_t (aka monotime)
         with the number of micro-seconds from an arbitrary point. No more messing with tv_sec/tv_usec.
         Simple routines are provided for measuring elapsed milli-seconds or elapsed micro-seconds (the
         most common use case for a monotonic timer). No worries about time moving backwards.
      2. High-speed assembler implementation for x86 and ARM. The standard method for retrieving the
         monotonic clock is POSIX.1b (1993): clock_gettime(CLOCK_MONOTONIC, timespec*). However, most
         modern processors provide a constant speed instruction clock which can be retrieved in a fraction
         of the time that it takes to call clock_gettime. For x86, this is provided by the RDTSC
         instruction. For ARM, this is provided by the CNTVCT_EL0 instruction. As a compile-time option,
         these high-speed timers can be chosen. (Default is POSIX clock_gettime.)
      3. Refactor of event loop timers. The timer processing in ae.c has been refactored to use the new
         monotonic clock interface. This results in simpler/cleaner logic and improved performance.
      c01e94a4
  2. 05 Dec, 2014 1 commit
  3. 07 Aug, 2014 1 commit
  4. 30 Jun, 2014 1 commit
  5. 17 May, 2013 1 commit
  6. 12 Dec, 2012 1 commit
  7. 08 Nov, 2012 1 commit
  8. 28 Aug, 2012 1 commit
    • antirez's avatar
      Incrementally flush RDB on disk while loading it from a master. · 784b9308
      antirez authored
      This fixes issue #539.
      
      Basically if there is enough free memory the OS may buffer the RDB file
      that the slave transfers on disk from the master. The file may
      actually be flused on disk at once by the operating system when it gets
      closed by Redis, causing the close system call to block for a long time.
      
      This patch is a modified version of one provided by yoav-steinberg of
      @garantiadata (the original version was posted in the issue #539
      comments), and tries to flush the OS buffers incrementally (every 8 MB
      of loaded data).
      784b9308
  9. 29 Sep, 2011 1 commit
  10. 01 Jul, 2010 1 commit
    • antirez's avatar
      redis.c split into many different C files. · e2641e09
      antirez authored
      networking related stuff moved into networking.c
      
      moved more code
      
      more work on layout of source code
      
      SDS instantaneuos memory saving. By Pieter and Salvatore at VMware ;)
      
      cleanly compiling again after the first split, now splitting it in more C files
      
      moving more things around... work in progress
      
      split replication code
      
      splitting more
      
      Sets split
      
      Hash split
      
      replication split
      
      even more splitting
      
      more splitting
      
      minor change
      e2641e09
  11. 02 May, 2010 2 commits
  12. 07 Jan, 2010 1 commit
  13. 27 Mar, 2009 1 commit