[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