On Tue, Jun 23, 2020 at 6:33 PM Deepak Sirone <deepaksiron...@gmail.com> wrote:
> > Process A sends a message to B using the "encoding/gob" package to write > to the socket which is subsequently decoded. After sending a message, A > waits for a response from B. B does some processing on the message and > sends a reply back. > > Things I would consider: * How large are the messages? If they are small, you are measuring a switching overhead. Consider batching work into larger groups so the switching overhead amortizes over multiple messages. * Usually, encoding is much faster than decoding. In a typical environment, the encoder already has type information, so it can just lay out data and stream it. The decoder has to look at bytes and switch to re-raise the type information. * Consider pipelining. If you run stop-and-go, you will be limited by the switching time of the operating system. Feed the pipe from the sender, handle messages on the receiver side. If messages vary by work, consider out-of-order processing with a tagging scheme (see e.g., the 9p protocol for a simple way into this). * Look into micro-batching tricks. They tend to perform well when there is processing overhead. * Addendum: If you stop-and-go, you are cooperating between the A/B process pair. This is bound to give you skewed benchmarks because the speed of one side severely affects the behavior of the other side. * If the two processes lives on the same machine, why even keep them separate? A goroutine with a channel between them is probably better use of the hardware. If the two processes ought to live on separate hardware, the above notion of a (bandwidth*)delay becomes far more important since networks are measured in milliseconds in most cases. In general: I prefer changing the strategy over tuning for speed. It is bound to yield much better results in the long run in my experience. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiW2Jvo-%2B3uVj1WA24DX21NoVRb7dOiD3XhryF_CNbqt1A%40mail.gmail.com.
