Python vs C++ (May 2024)

So this is my story with my last Master's class team project.

Our team project was to create a Shazam for Videos. You have a pile of videos, approximately 30 hours in length. Given a 30-second video clip (which may have different resolution/color space/sampling rate/extension, etc.), we must identify the video it is included in and find the timestamp where that clip starts.

I was pretty confident that Python would be very suitable for this task. Alas, there is a mantra in software engineering:

Don't blame [language] for being slow. It's your code that's slow.

I can't exactly find out who first said this, but fair enough, I've seen so many cases. Even more, the nice Python syntaxes and wrapped APIs often give additional time to plug and play higher-order speed improvements, such as multiprocessing and producing faster code, given the same human hours. Writing multiprocessing in C++ is a hassle, whereas in Python, you can convert a single-processed program into a multi-processed one in less than 20 minutes.

In this case, Python will have PIL and OpenCV, which are already battle-tested, and throwing in some simple optimizations would be more than enough. I also thought that Python's syntax would've 10x our dev time, and thus, I am sure we will have to use Python in the end.

I've done some initial research and used perceptual hashing (v. ahash, dhash) to investigate audio matching, SIFT (scale-invariant feature transform), etc. A naive calculation took around 10 minutes to identify a video with decent accuracy, and I made some optimizations to skip frames (around 30 frames per time, using prime numbers). I also threw in multiprocessing, ending up with code with around 80% accuracy in around 40 seconds of runtime. If I reduce the skip-frames (used for optimizations), the accuracy climbed to 90%, but at double the runtime. It was a typical make-a-compromise situation, but I was proud and thought I could've called it a day.

Then there was Louis. Louis was the opposite type of developer than I was. Maybe I was the type of startup engineer who values dev-hour efficiency more, whereas he was the type of performance engineer who values CPU-cycle efficiency more. He was adamant that we had to move to C++ due to performance issues. To be fair, we did need a little better performance-accuracy. We needed near-100% in less than a minute, but I thought we would throw in more algorithms, such as audio profiling, to improve the accuracy while cutting some fat here and there (such as preprocessing) to make things faster.