-
gocv
Go package for computer vision using OpenCV 4 and beyond. Includes support for DNN, CUDA, and OpenCV Contrib.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
I have just found the gocv package. I have a video analyzer program written in python, however im thinking about rewriting on golang for optimizing the execution time. Its a good idea or its better to just use the phyton one.
Serialization overhead. Python has serialization overhead that is rather substantial, in my understanding, and seems(?) to have a cost per-field or per-byte. Large data marshalling can be legitimately slow in python. By contrast, go has per-pointer serialization overhead. You can preallocate a scratch space in C and send pointers out of that and bring the serialization cost down to nearly zero. I do something similar with https://github.com/cannibalvox/cgoparam although it's intended for relatively small amounts of data, it could be a good starting point for something else.
Be aware of #21827. (https://github.com/golang/go/issues/21827) - Locked OS threads should not park their goroutines under any circumstances. That means no blocking channel reads or writes, no time.Sleep, no go mutexes, etc. Right now if a thread-locked goroutine is parked, the os thread it's on is retired and it's moved to another P. Context switch. Then the park ends and the goroutine tries to run it, and it realizes it's on the wrong thread. It unretires its thread and moves back. Context switch. This will cause performance issues. Ideally, your locked os thread will use thread-blocking calls in C to wait for stuff, but for your use case, you should just not be afraid to spin your core, I think. You can still read from and write to channels. Just use buffered channels, and select{ case <-channel: // do stuff break default: }