--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Thanks Josiah,
I want to just add that ranges in O(log(N)) seek + O(M) to scan
elements is optimal in the context of the API exposed, you can do
better only with a linear array indexed by an integer index where you
have O(1) + O(M).
CSCORE 0
CSCORE '2.6686011349572752e-303
' BRSTART
becomes active.start
parameter may be negative, to get a preroll of sorted set elements before the actual start (total number of results will never be more than stop
- start
+ 1).I'm sorry that we duplicated work, however as a partial consolation
you should check my commit date: what I committed is code from 2012
:-)
So there was a duplication problem when you posted your PR 14 days ago already.
Well we can use this "race condition" to improve the design perhaps.
About walking by score, if it is for the sake of speed, I'm definitely
skeptical as a first reaction unless I see benchmarks, a profiling
attempt, an optimization effort, and then new benchmarks :-)
I *never* make an API more complex for the sake of speed unless it is
an order of magnitude difference that I can't help with other means.
To be honest the code saved itself in some way for 2 years sitting in
a local branch in my disk...
Just as an historical note on how I, and I bet most programmers change
their minds over time, I stopped the work because I was too concerned
with collation. Only later I realized not handling the collation was
like not handing encoding in Redis: a great idea...
> My implementation is mostly a subset of ZRANGEBYLEX anyway, ...
Oh if this is the case it's up to Pieter's refactoring of my original
code, I followed the same schema for my implementation.
I did some benchmarking. The
hardware is bare-metal typical Linux box running a recent kernel:
src ➤ redis-benchmark -P 32 -q -n 1000000 zrangebyscore z2 49999050 49999800
zrangebyscore z2 49999050 49999800: 128667.02 requests per second
src ➤ redis-benchmark -P 32 -q -n 1000000 zrangebylex z1'[0000499981'
'[000049999'
zrangebylex z1 [0000499981 [000049999: 112599.94 requests per second
Sorted sets cardinality is 1 million each, created with the same
random number generator.
There is little speed difference when accessing, both ranges are
designed to return 6 elements.
However I found that when creating the sorted sets there was a bigger
difference, ZADD performed better when scores where different.
Maybe this is because using the score it is like if the tree has
height+1 compared to the flat score but I did not profiled.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Cheers!
It is already in the list of LevelUP backends: https://github.com/rvagg/node-levelup/wiki/Modules
Hugues
You received this message because you are subscribed to a topic in the Google Groups "Redis DB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/redis-db/GrCM183WkxM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to redis-db+u...@googlegroups.com.