[Redis] Perl Redis Client news

Steffen Mueller smueller at cpan.org
Mon Nov 18 18:09:39 GMT 2013


On 11/18/2013 12:39 PM, Pedro Melo wrote:
> Then, we can have specialized modules that can give us more performance

That seems over-engineering the problem to me. In the end, more 
indirection is going to slow down the general case and be a drag in the 
corner cases as well. But that's just my 2c.

> if they are present/installed: the read-based code as a PP solution, or
> XS-based Redis protocol parsers, or even integration with hiredis.

Hmm, I've written a little bit of code against hiredis. IMO hiredis is 
not a very useful library for authors of wrappers since, last I checked, 
it required the user to build up the actual command string[1]. Which is 
kind of obnoxious if you think about it. One might as well pipe through 
the redis-cli. ;)

Now, a protocol parser written in C might be otherwise useful, but I'm 
not sure how much it's really going to speed up about finding line feeds 
in streams (man, I hate this about the Redis protocol!): That should be 
something that's hard to compete on with the perl guts. The actual 
dissemination could be sped up a little, of course. And an interface to 
a C library that puts together the command strings and does escaping 
where necessary could be quite handy. At the cost of having to deal with 
I/O (and likely Perl's socket data structures) from C.

What's the main benefit you'd hope for? Maybe there's an easy win?

--Steffen

[1] Example:
         reply = redisCommand(c,"LPUSH mylist element-%s", buf);




More information about the Redis mailing list