It is a good indication of what you can get, if you optimize your code. I think a better idea of performance is the latency, because that tends to matter a lot more for most applications. For that they are on par.
On Saturday, February 4, 2017 at 6:13:21 AM UTC-8, p...@configit.com wrote: > > But if the benchmark is a good indication of real world throughput, then > surely there is still reason to be concerned? Or do you mean that the > benchmark specific Java code (as in the benchmark application ) has been > optimized? > > On Saturday, February 4, 2017 at 1:30:37 AM UTC+1, Carl Mastrangelo wrote: >> >> The reason Java is fast is because there has been a lot more time spent >> in making the *benchmark* fast. Those numbers tell you what you can expect >> from an optimized gRPC server / client. The core reason Java is faster is >> likely because there was considerable time put into profiling that >> benchmark code. >> >> On Friday, February 3, 2017 at 9:57:06 AM UTC-8, Peter Tiedemann wrote: >>> >>> I was looking over the benchmarks here (1.0.0, master does not seem to >>> work): >>> >>> >>> https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5712453606309888 >>> >>> Mostly, it seems sensible enough, C++ is fastest, Java and C# roughly >>> tied. Then i took a look at the throughput tests, where Java shows ~10x >>> more QPS, leaving C# closer to Python and Node. >>> >>> Is there some performance issue with the C# implementation i need to be >>> aware of? >>> >>> >>> -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/2f61d594-9c5b-40fd-a9e7-bce91d73f136%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
