76
Good performance is not just big O
(jmmv.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Sep 2023
76 points (100.0% liked)
Programming
17443 readers
143 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
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 !webdev@programming.dev
founded 1 year ago
MODERATORS
Sure, you can make it 10x faster by optimizing the complexity, but I can improve throughput by 1000x by putting it on 1000 machines.
In practice, it’s a bit of both. Paying attention to Big-O and understanding the gross relative cost of various operations goes a long way, but being able to run an arbitrarily large number of them can get you out of a lot of jams.
My app is installed on 10000 phones! See how much better it runs!
And sometimes a co pletely different approach is better than focusing on the runtime of a single piece. We had a system that was sql code that ran many functions that scaled horribly as data was added to the system. Each function was as fast as could be measured, but the process of running them as separate repetitive functions ended up being over 24 hours in some cases.
Redoing them as a single stored procedure and optimizing that reduced it to a few minutes. This approach was much more complex than the individual functions and took about a year to replace what was oroginally written in 3 months.
Many times the effort to make something more efficient takes far longer than getting it to work in the first place, and many processes are slow because they did not allocate time to properly optimize or include staff that are able to optimize.