Is the opencv4 binding more efficient than python?

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

Nutrient - The #1 PDF SDK Library
Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.
nutrient.io
featured
CodeRabbit: AI Code Reviews for Developers
Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
coderabbit.ai
featured
  1. gocv

    Go package for computer vision using OpenCV 4 and beyond. Includes support for DNN, CUDA, OpenCV Contrib, and OpenVINO.

    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.

  2. Nutrient

    Nutrient - The #1 PDF SDK Library. Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.

    Nutrient logo
  3. 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.

  4. 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