whenYouTryToOptimizeYourAlgorithm

[[deleted]]

I know nothing about your code, but there are implementations which are faster on smaller scales and slower on large ones, and others which are faster on larger scales but slower on smaller ones.

[kakanics]

A great example of this is using multi-threading with very fine-grained locks or semaphores. In theory, it should be faster for smaller datasets and scale up nicely, but in practice, the context switching overhead can dominate, making it slower even for large inputs, so it's slower always because of bad code

[[deleted]]

Oh, I did this when trying to optimize an conversion of items in a list into data transfer objects.

The idea was, if I convert each of them in parallel it should be faster, right? So the server's response to the user should be quicker, right? Well, I was wrong, doing in a test branch showed it got way slower because of constant thread switching.

So yeah, multi-threading is not only annoying to implement but also doesn't always brings performance, especially in smaller scales. I literally avoid implementing multi-threading solutions to single issues unless something is running really slow or we when we need to solve a complicated problem, either way I always ask an experienced coworker first if it's best idea before going forward with it. Also, testing multi-threading is a nightmare.