Ivan Baidakou

Thank you for your query. Indeed, it seems the `drop_result` policy wasn't properly exposed for the API usage. What is your use-case for discarding the result?

PS. Will try to fix it on weekends.

Could you, please, try PR https://github.com/basiliscos/cpp-bredis/pull/24 ? How to use it is basically : ```cpp using Policy = r::parsing_policy::drop_result; ... c.async_read(rx_buff, read_callback, count, Policy{}); ``` the last 2 parameters are...

What you are asking for, is some kind of "partial result drop", meanwhile the `drop_result` policy discards result completely, i.e. you either do not care about it at all or...

@ovanes any news, so far? I have updated performance testing against `Redos`, and here are my results: ``` bredis (commands/s) | bredis(*) (commands/s) | redox (commands/s) ---------------------+------------------------+-------------------- 1.59325e+06 | 2.50826e+06...

@ovanes Thanks a lot for sharing the results. Let's keep that page, as it might be interesting for other people. I have also a few ideas how to improve performance...

Yes, please, go ahead. In the current implementation, it performs double-parsing, first pass to determine the end of expected reply (i.e .with drop policy), and the 2nd pass to deliver...

I think would be nice to have some switcheable matching policy. The one I proposed can be named "simple_matcher", and the original one "score_match" (or "fuzzy_matcher"). If it is OK...

I got an impression that keep order is exclusive to scores, which lead to the result above; and it seems by scores the shorter names pop up...

Seems fine for me! Thanks!