0

I am looking for information on native latency of processing event streams using RxCpp library, i.e. what is the library overhead of processing one simple message (for example, a pointer to an object)? How much time passes from an event being published by some source to it being finished processing by a trivial (does nothing) observer ?

I have done a lot of web-search, but do not seem to be able to find any benchmarks. I do not need exact numbers, but just the scale would be sufficient: is it milliseconds, microseconds, hundreds of nanoseconds?

raiyan22
  • 1,043
  • 10
  • 20
S.V
  • 2,149
  • 2
  • 18
  • 41
  • 2
    Be careful with web benchmarks you find on the internet, they are often compiled wrong or have mistakes especially with micro-benchmarking which is the case here. Do it yourself. –  Dec 24 '21 at 21:56
  • Having some scale estimate of the latency would help me to understand if it is worth to study the library documentation at all or I have to look for something else for my project. – S.V Dec 25 '21 at 03:06
  • What are you trying to do in the first place? –  Dec 25 '21 at 03:09
  • I am evaluating different C++ stream processing libraries to, hopefully, find one which might be suitable for my project, and there are not many unfortunately. I hoped that somebody has experience with RxCpp. But, since it does not look like anybody will be capable of helping me here to eliminate any options, I will have to follow your suggestion and do all the evaluations and benchmarking myself. – S.V Dec 25 '21 at 03:26
  • 1
    Stream processing libraries? There are plenty! From the top of my head: Tigon, LightSaber, Kafka, LogDevice, Aeron, Concord. Multiply this by 10 for Java. See a list here: https://github.com/manuzhang/awesome-streaming –  Dec 25 '21 at 03:34
  • Thank you for the link! My requirements are: it has to be C++, it has to have low latency (distributed systems are too slow for me; preference is for multi-threaded single process frameworks, i.e. I want shared memory), and it has to support arbitrary user defined complex transformations (organized as nodes of a directed acyclic graph) on input events from multiple sources. For a more simple project, I used WindFlow (https://paragroup.github.io/WindFlow/), which works great but does not seem to support observing by a single node of events of different types. I will have a look at LightSaber. – S.V Dec 25 '21 at 05:06
  • I am not sure if rxcpp is for you man, it looks very heavy and cumbersome. I just looked at the documentation and it is so strange. It looks like those Modern C++ wrappers full of syntax sugar but very little to back it up. You mentioned shared memory, multi threaded and stuff, there is nothing like that in there. It's just boilerplate code. –  Dec 25 '21 at 05:18
  • I am not sure either - that is why I asked this question. RxCpp looks powerful and flexible, and not so easy to set up some benchmark for it, but what is the computational cost in terms of latency? I am doing a ton of reading about it now and then will move to benchmarks. – S.V Dec 25 '21 at 05:36
  • I mean, we talk about latency when you're sending data over the network but not on the same box. On the same process or even cross process I HOPE you are doing everything in the low nanoseconds. –  Dec 25 '21 at 05:42
  • I achieved low hundreds of nanoseconds with several data transformation nodes applied on one data message and it can be improved, and in the case described in my question that would be about 80ns (that is the number I want to compare to for RxCpp). – S.V Dec 25 '21 at 05:52
  • It really depends what "data transformation" means. If it's just an integer addition or a complex regex search on several megabytes of data. I had once a chain of events with 200 callbacks that took a bit more than 500 nanos. It really depends. –  Dec 25 '21 at 05:53
  • I need to know how fast a message will got from source to sink node if *nothing* is done to it. – S.V Dec 25 '21 at 05:55
  • Even then, are you just passing a pointer around? It's a couple of cycles. Is the message a few megabytes and you are copying it? That copy will take time. –  Dec 25 '21 at 05:56
  • Just passing a pointer, but this pointer has to go through a graph setup in a flexible and powerful stream processing framework (publishing, subscriptions, source and sink classes set up as graph nodes running in parallel threads). Not the case of `a=b` copy. – S.V Dec 25 '21 at 06:01
  • You seem to be describing some of those Modern C++ syntax sugar hills that many people die on. This is classic event processing that's better solved with virtual function calls and interface, in my opinion. –  Dec 25 '21 at 06:19
  • 1
    it would be useful for you to actually empirically benchmark the latency that you seek, then post the measured latency (and preferably a nutshell description of what/how was measured) as an answer to your own question. This is a good valid question whose answer needs to exposed for all of the reactive frameworks across all languages, not merely RxCpp for C++ (but we need to start somewhere, don't we?). – Andreas ZUERCHER Feb 16 '22 at 03:05

1 Answers1

0

rxcpp mostly syntax sugar but not only. It is a framework to build streams via bunch of operations applied to your data. As a contributor to rxcpp i can say, that after several recent commits performance should be a bit better (due to elimination of significant amount of copy/move calls over original objects). Anyway, internally it just passed objects into functions, send gotten values to next blocks and etc.

Anyway, internal logic is pretty straightforward for most operators (let's say, map or filter) and it is nothing else than obtaining value by universal reference, passing to user-defined lambda and passing value next. So, you will take overhead only by passing values and etc.

If you are interested in a specific amount of copies per operator, you can check unit tests inside rxcpp, i've added tests for each operator.

Victimsnino
  • 11
  • To rephrase my original question: please, let us know if you have any unit tests in RxCpp, which could be used to estimate the computational cost of all the *"syntax sugar"* and of all the beautiful interfaces in the library? – S.V Dec 28 '21 at 20:33