On Mon, Sep 17, 2018 at 12:17 PM, changkun <euryugas...@gmail.com> wrote: > > Those overhead you mentioned come from goroutine scheduler for entering a > system call. > Apparently, there is no such mechanism in Go to submit an IO "transaction" > if there are two > or more syscall close to each other, syscall can be held in OS thread > without exit back to goroutine > and save redundant bookkeeping, isn't?
That is correct: there is no such mechanism in Go. > Then, what about the net package? Socket pair FDs are pollable thus can > converted to net.Conn. > What happened to them and why it's performance even much "worse" than pure > syscall and close to > Cgo calls? Is the benchmark measured in a wrong way? Are all I/Os call via > net package suffering it? The net package is quite different from direct syscalls. The net package is optimized for handling intermittent I/O on many thousands of different descriptors. The net package uses a runtime poller so that each separate descriptor does not require its own dedicated thread. That introduces more bookkeeping and more overhead. It's the right choice for an HTTP server but will not be the best choice for the highest possible I/O throughput on a single descriptor. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
