Commit Graph

7 Commits

Author SHA1 Message Date
antirez
1b1f47c915 command lookup process turned into a much more flexible and probably faster hash table 2010-11-03 11:23:59 +01:00
antirez
3856f14759 This should fix Issue 332: when there is a background process saving we still allow the hash tables to grow, but only when a critical treshold is reached. Formerly we prevented the resize at all triggering pathological O(N) behavior. Also there is a fix for the statistics in INFO about the number of keys expired 2010-09-15 14:09:41 +02:00
antirez
e0be2289e9 hash table example commented out in dict.c 2010-07-27 10:00:38 +02:00
Benjamin Kramer
399f2f401c Add zcalloc and use it where appropriate
calloc is more effecient than malloc+memset when the system uses mmap to
allocate memory. mmap always returns zeroed memory so the memset can be
avoided.  The threshold to use mmap is 16k in osx libc and 128k in bsd
libc and glibc. The kernel can lazily allocate the pages, this reduces
memory usage when we have a page table or hash table that is mostly
empty.

This change is most visible when you start a new redis instance with vm
enabled.  You'll see no increased memory usage no matter how big your
page table is.
2010-07-25 00:11:20 +02:00
Benjamin Kramer
d9dd352b36 Remove _dictAlloc and friends
zmalloc calls abort() so _dictPanic will never be called.
2010-07-24 23:10:42 +02:00
Benjamin Kramer
b1e0bd4b9b Reduce code duplication 2010-07-24 22:37:01 +02:00
antirez
e2641e09cc redis.c split into many different C files.
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
2010-07-01 14:38:51 +02:00