That doesn’t seem to match up with the pprof report - although it would be easier to determine if you showed the back-traced the syscalls. The original pprof report you stated was from without channels, thus the syscalls are almost certainly related to IO. Maybe you could clarify why you think it is not IO bound? Just using buffered IO won’t necessarily make it not IO bound - depends on the amount of IO compared to other work.
When you add channels to a program, you are adding another set of context switches and signalling - between the readers and writers - so that will be overhead. A program without channels using multiple Go routines is typically faster than one using channels - the use of channels makes concurrent programming easier, not more efficient. > On Feb 4, 2019, at 9:32 AM, Andrew Medvedev <andrew.y.medve...@gmail.com> > wrote: > > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
