And if that is the case, the most likely way to speed up you program would be to send the route updates in a batch to the kernel - not sure that this is even possible.
> On Feb 4, 2019, at 9:56 AM, robert engels <reng...@ix.netcom.com> wrote: > > Also, to clarify, in the absence of more details, I would consider > netlink.RouteReplace to be an IO operation - it is calling into the kernel > (most likely). Whether that should be considered IO is probably a matter of > opinion. > >> On Feb 4, 2019, at 9:32 AM, Andrew Medvedev <andrew.y.medve...@gmail.com >> <mailto: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 >> <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 >> <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 > <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.
