summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorantirez <antirez@gmail.com>2014-05-06 12:10:22 +0200
committerantirez <antirez@gmail.com>2014-05-07 16:12:32 +0200
commit76fda9f8e10eb9cf1299fa6ca04f60d79462759e (patch)
tree057b19b10da1bec0a402a7bf8f24617aeef48bd1
parent48c49c485155ba9e4a7851fd1644c171674c6f0f (diff)
downloadredis-76fda9f8e10eb9cf1299fa6ca04f60d79462759e.tar.gz
Scripting: don't call lua_gc() after Lua script run.
Calling lua_gc() after every script execution is too expensive, and apparently does not make the execution smoother: the same peak latency was measured before and after the commit. This change accounts for scripts execution speedup in the order of 10%.
-rw-r--r--src/scripting.c18
1 files changed, 17 insertions, 1 deletions
diff --git a/src/scripting.c b/src/scripting.c
index b893a4a12..7537f37de 100644
--- a/src/scripting.c
+++ b/src/scripting.c
@@ -943,7 +943,23 @@ void evalGenericCommand(redisClient *c, int evalsha) {
}
server.lua_caller = NULL;
selectDb(c,server.lua_client->db->id); /* set DB ID from Lua client */
- lua_gc(lua,LUA_GCSTEP,1);
+
+ /* Call the Lua garbage collector from time to time to avoid a
+ * full cycle performed by Lua, which adds too latency.
+ *
+ * The call is performed every LUA_GC_CYCLE_PERIOD executed commands
+ * (and for LUA_GC_CYCLE_PERIOD collection steps) because calling it
+ * for every command uses too much CPU. */
+ #define LUA_GC_CYCLE_PERIOD 50
+ {
+ static long gc_count = 0;
+
+ gc_count++;
+ if (gc_count == LUA_GC_CYCLE_PERIOD) {
+ lua_gc(lua,LUA_GCSTEP,LUA_GC_CYCLE_PERIOD);
+ gc_count = 0;
+ }
+ }
if (err) {
addReplyErrorFormat(c,"Error running script (call to %s): %s\n",