Is the node.js sdk faster than the .net sdk because of libcouchbase

Is the Node.js SDK faster than the .NET SDK due to the Node.js SDK using libcouchbase? I am trying to decide what SDK to use.

I don’t know that any specific comparison benchmarks have been performed, but I definitely wouldn’t make that assumption.

  • The .NET SDK makes extensive use of JIT optimizations and Span to get high performance on modern .NET versions. In theory it should at least be getting close to C++ performance on modern .NET versions once it’s run for a bit for optimizations to fully apply, though I have no specific evidence to back that up.
  • While libcouchbase and therefore the background communication layer is multi-threaded, the JS code being run in Node is single-threaded and can only use one CPU core

There are also a lot of tweaks you can do to increase the performance within the .NET SDK:

  • Use .NET 6
  • Certain types of logging/monitoring/tracing can be disabled to reduce overhead
  • There are several settings that can be tuned for your workload, such as pool sizes, etc
  • If using an older SDK version, be sure to turn on the Channels connection pool experiment (it’s on by default in newer versions)

I am using .net framework.

The reason I am using it is that I need to make it into a COM object so that a legacy win32 app can talk to couchbase. I know that .net 6 can do COM, but I don’t know how to make it work (you need to generate a TLB file manually).

However, I may just create a .net 6 windows service that my win32 app talks to over a socket if .net framework is so slow.

I know that if I was writing such an application, I would create a service and not mess with COM. The .NET SDK is pretty strongly tuned for asynchronous operations. It would be very difficult to get asynchronous operations to flow across COM. You’d have to have start operations and then fire events back when the operations completed. On the other hand, a service communicating over HTTP or GRPC would tend to make async much easier. It would also avoid using a very old, difficult, and outdated technology. Finally, it would allow the .NET side to run in 64-bit even if the other app was 32-bit for better performance.

1 Like