diff options
author | antirez <antirez@gmail.com> | 2014-05-06 12:10:22 +0200 |
---|---|---|
committer | antirez <antirez@gmail.com> | 2014-05-07 16:12:32 +0200 |
commit | 76fda9f8e10eb9cf1299fa6ca04f60d79462759e (patch) | |
tree | 057b19b10da1bec0a402a7bf8f24617aeef48bd1 | |
parent | 48c49c485155ba9e4a7851fd1644c171674c6f0f (diff) | |
download | redis-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.c | 18 |
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", |