Is the opencv4 binding more efficient than python?

This page summarizes the projects mentioned and recommended in the original post on reddit.com/r/golang

Our great sponsors
  • Mergify - Automate your Pull Request with Mergify
  • Scout APM - Less time debugging, more time building
  • SonarLint - Clean code begins in your IDE with SonarLint
  • gocv

    Go package for computer vision using OpenCV 4 and beyond.

    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.

  • cgoparam

    Fast, thread-safe arena allocators

    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.

  • Mergify

    Automate your Pull Request with Mergify. Mergify is the most powerful merge queue tool that offers speculative checks, batch merges, and multiple queueing options. Coordinated with any CI and fully integrated to GitHub. Get started or request a demo!

  • go

    The Go programming language

    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: }

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts