I really like what i have seen so far wrt to functionality, so i am glad to hear that performance has been improved! Mostly i was concerned that C#/.net in grpc was a bit of a "secondary" target without much support/optimization (for example, if you look at captn proto, the C# implementation is done on the side, and is a bit unsupported).
On Wednesday, February 8, 2017 at 6:44:49 PM UTC+1, Jan Tattermusch wrote: > > Hi, > > C# performance have been improved by a lot since 1.0.0 release (from > August 2016). > The results on upstream/master are temporarily broken for unrelated > reasons, but normally you would see that the C# performance have been > improved drastically between 1.0.0 and 1.1.0 (which is the latest release - > see release notes in https://github.com/grpc/grpc/releases/tag/v1.1.0 that > mentions some details about the performance improvement and how to get the > best numbers). > > We'll try to provide a dashboard that corresponds to the 1.1.0 release. > We are planning to bring more optimizations to C# in the future. > > Jan > > > > On Wed, Feb 8, 2017 at 9:19 AM, 'Nicolas Noble' via grpc.io < > [email protected] <javascript:>> wrote: > >> Also what's the platform requirement? I think these numbers are from >> Linux... >> >> On Wed, Feb 8, 2017, 08:53 'Carl Mastrangelo' via grpc.io < >> [email protected] <javascript:>> wrote: >> >>> It is if you optimize your code. What kind of latency / throughput >>> numbers are in your requirements? >>> >>> >>> On Wednesday, February 8, 2017 at 2:34:41 AM UTC-8, Peter Tiedemann >>> wrote: >>>> >>>> But do you mean if i optimize *my* code, or if someone optimizes the >>>> *grpc* C# code base? >>>> >>>> I am naturally concerned with how high priority .Net support has for >>>> grpc, as that is our primary platform :) >>>> >>>> On Tuesday, February 7, 2017 at 12:48:26 AM UTC+1, Carl Mastrangelo >>>> wrote: >>>>> >>>>> 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, [email protected] >>>>> 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 [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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/9d3b7f37-16b6-493b-a644-6a26f83aad35%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/9d3b7f37-16b6-493b-a644-6a26f83aad35%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/CAOWnRi9HSq9C-75jkc7-JrTLQQ5i9GptwkR%2B-mSHKahAbyWh7g%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/grpc-io/CAOWnRi9HSq9C-75jkc7-JrTLQQ5i9GptwkR%2B-mSHKahAbyWh7g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/92b8bdb8-a8e5-428b-adb1-b1f875daae9c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
