Two tips from writing github.com/twpayne/go-geos (Go bindings for the popular GEOS geometry library), where I also encountered performance problems with cgo when calling small C functions:
1. Make each cgo call do more by moving common combinations of functions in to C, i.e. use a higher-level API. Example: this function <https://github.com/twpayne/go-geos/blob/master/geos.c#L9-L25> moves a for loop over an element lookup function from Go to C. In this particular case, this saves hundreds or thousands of cgo calls. 2. Eliminate cgo calls where possible. Example: this function <https://github.com/twpayne/go-geos/blob/master/geom.go#L80-L108> copies commonly-used data from C into a Go struct (i.e. caches them in Go) so cgo calls are not required are not required to retrieve those properties. Regards, Tom On Friday, January 21, 2022 at 11:06:12 AM UTC+1 Sean wrote: > Hello Ian, > > Thank you for the answer. > > I'm currently using Cgo heavily for a game. But microseconds don't > matter to me. The calls must not exceed milliseconds, and it all depends > on the C api I wrote. > I'm currently in testing and development, there doesn't seem to be a > problem now but I don't know what to do if Cgo in production will be a > problem for me. > Dropt this wonderful std and switching to C++ will be a nightmare for me. > > I'm trying some untested things in the Golang world. > > Hopefully, CFFI performance will eventually get on the Golang team's > radar and improve. > > On 20/01/2022 23:25, Ian Lance Taylor wrote: > > On Thu, Jan 20, 2022 at 2:54 AM Sean <s.tolst...@gmail.com> wrote: > >> I know CGO is not performing well in Golang at the moment. > > That is true, but we should quantify it. The last time I tested it, a > > cgo call took about 10 times as long as an ordinary function call. So > > that is pretty bad if you are calling a tiny function, but it doesn't > > really matter if you are calling a function that does I/O. > > > >> If we use a dll will this performance issue decrease? > > I don't know but I don't think so. > > > >> If I do the cgo calls with syscall, will there be no performance > improvements? > > I haven't measured but I don't see why using the syscall package would > > be any faster. > > > >> When I think about it, Golang always has to make syscall calls on the > os it's running on. For example, in Windows, the net package has to talk to > the socket api of Windows. > >> My assumptions are that syscall should be better than Cgo. > >> If syscall calls are no different from Cgo, how does Golang build this > performance in the core library? > > The Go runtime has two advantages. First, it can make the call > > directly in the system ABI rather than having to translate from the Go > > ABI to the system ABI. Second, it can know that certain system calls > > can never block, and can use that to optimize the way that they are > > handled. > > > > Also, of course, system calls by their nature tend to be a bit slow, > > so the overhead is less important. As mentioned above, the overhead > > of a cgo call is most important when calling a small C function. Most > > system calls are not small. > > > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dceda1be-e47a-4da2-b80c-a6fcefe7a769n%40googlegroups.com.
