3 ms·
Interesting, I need to dig into the guts of this because this seems cool. I'm a bit out of practice with Go but I never thought that the channels were "slow",
by tombert 1y ago
Interesting, I need to dig into the guts of this because this seems cool.
I'm a bit out of practice with Go but I never thought that the channels were "slow", so getting 4-10x the speed is pretty impressive. I wonder if it shares any design with LMAX Disruptor...
- bob1029 1y ago> I wonder if it shares any design with LMAX Disruptor... I've recently switched from using Disruptor.NET to Channel<T> in many of my .NET implementations that require inter-thread sync primitives. Disruptor can be faster, but I really like the semantics of the built-in types. https://learn.microsoft.com/en-us/dotnet/core/extensions/channels https://learn.microsoft.com/en-us/dotnet/core/extensions/cha... https://learn.microsoft.com/en-us/dotnet/api/system.threading.channels.channel-1?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.threadin...
- tombert 1y agoI've never used Disruptor.NET, only the Java version. I personally will use traditional Java BlockingQueue for about 95% of stuff, since they're built in and more than fast enough for nearly everything, but Disruptor kicks its ass when dealing with high-throughput stuff.
- bob1029 1y agoThe .NET version is compelling because it has a special variant called ValueDisruptor that can take a struct instead of a class. This gives it a big edge in certain use cases: https://medium.com/@ocoanet/improving-net-disruptor-performance-part-3-introducing-the-valuedisruptor-5b467730bbe https://medium.com/@ocoanet/improving-net-disruptor-performa...