Hi Robert The program is not IO bound. Sorry for not giving out the source code in the first place, here is a no-channel version https://github.com/andrewmed/loadroutes/blob/master/cmd/main.go and here is a slower channels version https://github.com/andrewmed/loadroutes/blob/test/channels/cmd/main.go both versions use bufio and profiling info does not suggest substantial IO waiting times.
In terminology of boundness, I think, the program is "syscall" bound, it is the receiving end for the program. Again I am not sure I personally am able to do anything about it My question is, how comes that adding one channel on producer where slower part is the "receiver" end (that is, producer is blocked waiting for receiver channel become available) adds to total runtime 2s compared to no-channels "only fn-callback" version. Is this a necessary cost of synchronizing on over 400_000 values over a channel? On Monday, February 4, 2019 at 3:56:32 PM UTC+3, Robert Engels wrote: > > Reading and writing to a channel has locks behind the scenes. Locks are > implemented with futexes. > > If your program is IO bound the simplest solution is often to use > buffering in the IO to perform more work per IO operation. > > > -- 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.
