Programming

17123 readers

171 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

Good performance is not just big O (jmmv.dev)

submitted 1 year ago by [email protected] to c/[email protected]

12 comments fedilink hide all child comments

Having a fast and responsive app is orthogonal to “knowing your big Os”. Unfortunately, most tech companies over-emphasize algorithms in interviews and downplay systems knowledge, and I believe that’s one reason behind sluggish apps and bloated systems.

I’ve seen this play out repeatedly. Interviewers ask a LeetCode-style coding question, which is then followed by the ritual of discussing time and memory complexity. Candidates ace the answers. But then… their “real” code suffers from subtle yet impactful performance problems.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 11 points 1 year ago

Big O is a useful tool, but it doesn't directly translate to performance. Understanding how systems work is a lot more useful and important if you really care about optimization and performance.

This is something I learned pretty early on as a professional developer. I got a computer science degree and was taught data structures, algorithms, and big O. In my first job, I came across a small piece of Java code that was being run a lot that had a small list being searched each time. I figured converting to a HashSet would be faster, but in testing it was actually slower. I forget the exact details, but I learned to test my assumptions about performance and not to just blindly change things.

My degree, for the most part, did not prepare me for working with large, interconnected systems. The only course that came close was an elective called "concurrent programming" which was really just "algorithms, but parallel".