C++ service (both, sync and async) is much slower than Go service.

50 views
Skip to first unread message

jeetpa...@gmail.com

unread,
Dec 13, 2018, 9:09:54 AM12/13/18
to grpc.io
Hi all,

To learn about gRPC in C++, I am creating a simple service in which the client would send two numbers, and a math operator as a string. The server would do the math operation and send back the result. It would be a single client opening a bidirectional stream and sending a million such requests.

When I create the server using Go, the million requests-responses take around 3 seconds. The C++ sync server takes around 20 seconds, and the C++ async server takes around 15 seconds for the same.

I was expecting the C++ server to be faster. I don't know if I'm doing anything wrong in C++. I have put up my code at https://github.com/jeet-parekh/grpc-demo. I would appreciate any suggestions for improving the performance of the C++ server.

Thanks!

Robert Engels

unread,
Dec 13, 2018, 9:28:32 AM12/13/18
to jeetpa...@gmail.com, grpc.io
gRPC uses dynamic memory (malloc) during message processing (lots of string) It is also concurrent. Concurrent Dynamic memory is faster in a GC environment. Go will be faster in these types of tests - you are really only testing allocation and deallocation since the operation is trivial. 
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b78f6e3b-3d7d-4bf3-815b-6f9c1681d3db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jeetpa...@gmail.com

unread,
Dec 13, 2018, 10:21:04 AM12/13/18
to grpc.io
Got it. So that's the internals of gRPC. And there's absolutely nothing I could do to make this faster... right?

Robert Engels

unread,
Dec 13, 2018, 10:24:21 AM12/13/18
to jeetpa...@gmail.com, grpc.io
That’s only my opinion based on reviewing your code and seeing how c++ maps protobuf types. 

I would just run both under a profiler but I am guessing you are going to see heavy calls to malloc and free on the c++ side. 

There may be options for message pooling on the c++ side - someone more familiar with that api would need to chime in. 
Reply all
Reply to author
Forward
0 new messages