It supports offline queue for commands, automatic socket reconnection,
command rollback mechanism for subscriptions and incomplete transactions,
moreover, it supports caching for LUA scripts.
https://github.com/rootslab/spade
Help or comments are appreciated, take a look!
--
Job board: http
Have a good fun ;)
Il giorno sabato 20 aprile 2013 18:37:28 UTC+2, mscdex ha scritto:
>
> On Apr 20, 12:22 pm, rootslab <44ga...@gmail.com> wrote:
> > The parsing datarate it's mainly dependent on pattern length, the data
> > length and pattern occurrences ( also
w says ;).
Il giorno sabato 20 aprile 2013 17:29:35 UTC+2, mscdex ha scritto:
>
> On Apr 20, 11:07 am, rootslab <44ga...@gmail.com> wrote:
> > I present some typical results for Qap and Bop (as you will see in
> > benchmarks) with *700 MB test Buffer and 225917 occurre
test Buffer and 225917 occurrences of boundary:*
*for Bop -> *
https://github.com/rootslab/bop
*
*
*node bench/small-pattern-data-rate.js 700 2*
- building test buffer 700MB
- current pattern:
"---2046863043300497616870820724\r\n"
- pattern copied* 225917 *ti
the best in terms of memory consumption and data
rate is QuickSearch.
My js implementations of these algorithms have reached data rate of ~ 20
Gbit/sec on my cheap laptop, for a short pattern like those for the
multipart/form-data streams.
You can test some results https://github.com/rootslab
n, for now, I can't compare the parsing data rate of buffertools respect
to qap <https://github.com/rootslab/qap> or bop
<https://github.com/rootslab/bop>modules ( varying the pattern size, from
small to very big ).
Anyway, it's not the point, like @mikeal said, it'
Hello folks!
A little question: in future releases of nodeJs, is it planned to add a
method like '*Buffer.indexOf'* ?
Using some well known pattern-matching algorithms, it could be possible (
running the best algorithm based on the size of the pattern to search ) to
reach a very good parsing da