How to use judy array lib properly in golang?

Question

In golang, the way calling C library is different from what's used in other mainframe dynamic language like PHP / Python / Java because Golang has a different multitasking mechanism which is not OS thread based, so call c function may result in a context switching or thread switching as I understand. In my project I'm trying to use Judy Array in Golang (as a queue worker) to do some simple but large amount dict-related calculation like "select distinct", so

What's the best practice to involve such c lib (for relatively high density calculation) and minimalise the performance overhead introduced as much as possible?

Answer 1

Despite the title, the question here really has two parts: a generic one about golang and C-interfacing for efficiency, and a specific one about performant use of judy arrays.

This thread seems to summarize the costs: https://groups.google.com/forum/#!topic/golang-nuts/RTtMsgZi88Q , so yeah its expensive compared to straight C, and you should try to minimize the crossover points from Go to C.

Here's additional, judy array specific advice: I've used judy arrays before in C/C++ code. The library's interface is not intuitive in certain places. And by default it uses a C-macro based API, which makes it tricky to get the interface usage correct because the compiler can't offer as much help as usual.

What I recommend, therefore, is that you write your tests and benchmarks in C first, so you understand the API and its weird cases. Judy arrays when benchmarked for my application (vs C++ vector of strings) were 3x faster, so it can be worth it. But break the task into three phases. First do what you want to do in C, and make sure it works as expected in your own C code. Then expand the basic C interface to handle batches of what you need done, so as to minimize the number of Go->C switches. Then bind your new C interface from Go.

Answer 2

If you are starting the binding for the library from scratch, I'd start by using cgo in the most straight forward way possible, and then see whether the performance meets your requirements.

If it doesn't, try minimising the number of C calls you make in commonly called spots. As you've already mentioned in the question, Go switches to a different stack when it makes a C call and this will affect the performance if you make lots of cgo calls to trivial functions. So one way to improve performance is to reduce the total number of C calls.

For example, if you need to call multiple C functions to implement one operation in your Go API, consider whether you could write a small shim C function that could combine those calls.

If the API you're wrapping deals with a lot of strings, this can show up if you've got many calls like:

func foo(bar string) {
    cBar := C.CString(bar)
    defer C.free(unsafe.Pointer(cBar)
    C.foo(cBar)
}

Which is three C calls. If the API you're wrapping can deal with unterminated strings, one option here is to pass a pointer to the string to a wrapper, and use the GoString type defined in the generated _cgo_export.h . For example, on the Go side:

func foo(bar string) {
    C.foo_wrapper(unsafe.Pointer(&bar))
}

And on the C side:

#include "_cgo_export.h"
void foo_wrapper(void *ptr_to_string) {
    GoString *bar = ptr_to_string;
    foo_with_length(bar->p, bar->n);
}

As long as the library doesn't hold on to the string data past when foo_wrapper returns, this should be safe.

There are probably some other optimisations that could help, but I'd strongly recommend keeping things simple initially and put your efforts into optimising the areas that matter.