Most performance issues aren’t in your code… and it took me too long to accept that
Posted by OliverPitts@reddit | programming | View on Reddit | 11 comments
For the longest time, every time something was slow, i assumed:
“my code is inefficient”
so i’d start optimizing logic, refactoring functions, etc.
but after working on a few real systems, i’ve noticed a pattern:
a lot of the time the issue is actually:
• network calls
• database queries
• third-party services
• unoptimized assets
not the core code itself
now i try to measure first before touching anything
curious if others had the same realization or is it just me?
sweetno@reddit
Aren't network calls and database queries in your code?
maxymob@reddit
Yesn't. The code makes the call/query but it can be slow for reasons outside the scope of the code.
sweetno@reddit
Why use slow calls/queries, when there are fast ones?
PineapplePiazzas@reddit
Why did you get downvoted, was it wrong that
"it can be slow for reasons outside the scope of the code."
?
Mr_Canard@reddit
Because there are a lot of bots in this subs that upvote specific content and downvote everything else.
Mr_Canard@reddit
Yes but to improve performance you may not need to change anything in your code itself. For example adding an index in the database.
redGNU@reddit
Your link doesn't even link to an article, just a marketing page.... bit low effort, no?
Empanatacion@reddit
This is my beef with the big O fixation in leetcode. You're supposed to chase a convoluted solution to get the optimal algorithm when in the real world, n is usually just a few dozen and minimizing i/o is the far more important concern.
pohart@reddit
Nah. Big O compounds with I/O.
The fact that I've got an N^3 running out to the network on every "step" is why my service is slow.
Empanatacion@reddit
With a low N and a high coefficient on the IO (which is most of the time), it can be faster to opt for a crappier big O that avoids IO.
But mostly my issue is that the leetcode mentality trains the juniors not to focus on simplicity and maintainability.
zshift@reddit
You’re conflating code with algorithms. Any code that needs to send or receive data to or from another device (eg SSD, Network controller, etc), your CPU has to wait thousands of cycles or more before continuing. If you aren’t using some form of lock-free concurrency, then your CPU will be doing nothing while waiting for the call to finish, significantly slowing down your program. When network latency spikes to 100+ milliseconds, that’s tens to hundreds of millions of clock cycles—depending on CPU clock speed—spent doing nothing.
For GUI applications, it’s a very common pattern to have a main UI that handles drawing the screen and briefly handling user inputs while actions that need lots of CPU or make IO calls must be sent to one or more background threads. This is to prevent the UI thread from locking up.