Sorry, I meant to send this on the http2 thread - and I also sent prematurely :(
> On Nov 13, 2021, at 2:11 PM, robert engels <reng...@ix.netcom.com> wrote: > > As another data point, I decided to test a few implementations of http2 > downloads on OSX. > > Using a Go server with default frame size (16k): > > Go client: 900 M/s > Java client: 1300 M/s > curl: 1500 M/s > > Using a Java server with default frame size (16k): > Go client: 670 M/s > Java client: 720 M/s > curl: 800 M/s > > Using Go server with 256k client max frame size: > Go client: 2350 M/s > Java client: 2800 M/s > curl: unable to set option > > Using Java server with 256k client max frame size: > Go client: 2900 M/s > Java client: 2800 M/s > curl: unable to set option > > > Clearly using a Go based server is the way to go :) > > But there also seems to be an opportunity to improve the Go http2 client > performance. > > >> On Nov 10, 2021, at 8:33 PM, Ian Lance Taylor <i...@golang.org >> <mailto:i...@golang.org>> wrote: >> >> On Wed, Nov 10, 2021 at 5:29 PM robert engels <reng...@ix.netcom.com >> <mailto:reng...@ix.netcom.com>> wrote: >> Hi, >> >> While investigating the http2 issue, I saw this in the profiler: (sorry for >> the screenshot) >> >> <PastedGraphic-1.png> >> >> and looking at the code: >> >> func syscall_syscall(fn, a1, a2, a3 uintptr) (r1, r2, err uintptr) { >> entersyscall() >> libcCall(unsafe.Pointer(abi.FuncPCABI0(syscall)), unsafe.Pointer(&fn)) >> exitsyscall() >> return >> } >> >> This is implies that the runtime overhead to make the system call - in >> entersyscall() and exitsyscal() - is more than 10x the cost of doing the >> actual call. >> >> Am I reading this right? If so, is there any outstanding issues to try and >> optimize this? >> >> Btw, the call being performed is a simple write to a socket. >> >> I'm not sure I trust the profiling here: it's fairly likely that the time >> required by the system call itself is not being correctly attributed. But >> the general idea may be true: it does take time to record in the scheduler >> that we are entering a system call. This is also why cgo calls are slow. >> And, in fact, on macOS system calls are essentially cgo calls, because macOS >> requires us to go through the C based libSystem rather than simply executing >> a SYSCALL or SVC instruction. >> >> I don't know offhand whether there are any open issues for speeding up these >> calls, and I couldn't find any in a quick search. People who work on the Go >> runtime are well aware of the problem. >> >> 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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVJqwMttzrE3GXeQf%2BC%3DKVtGFz%3DaXv%3DNXxaunWngE9L6Q%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVJqwMttzrE3GXeQf%2BC%3DKVtGFz%3DaXv%3DNXxaunWngE9L6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>. > -- 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/5A864FCE-9769-44C4-BE1C-E40D33BE8467%40ix.netcom.com.
