23 ms·

I find BigO performance is very rarely the cause of bad performance. It's normally slow IO, timeouts, deadlocks etc I think I've actually seen performance decr

by UK-AL 4y ago

I find BigO performance is very rarely the cause of bad performance. It's normally slow IO, timeouts, deadlocks etc I think I've actually seen performance decreases by people trying to decrease BigO. BigO only starts to really dominate time when N reaches higher levels. At lower levels of N your performance on your constant operations matter more, and by implementing more complex algorithms actually decreased real time performance. Obviously a lot of nuance in this. But first you need to measure.

eyelidlessness 4y ago
I work on an application with some serious performance issues. Nearly all of them involve some combination of: - inefficient design around data dependencies and their identification - redundant work performed around said dependencies - excessive reliance on APIs for uses they’re not intended, which frequently causes… - …excessive VM deoptimizations and excessive GC Granted this is one application and I certainly don’t think it’s representative of anything. But it’s definitely a counterpoint to inefficient concurrency (where this app generally performs quite well).
trashtester 4y ago
Knowing WHEN to do BigO optimizations is part of knowing how to optimize. And for cases that _could_ ble NlogN, it may be perfectly fine to chose N^2 for moderate N, while N^3 can kill the solution. As for timeouts, IO and deadlocks, those problems can also be a case of poor up front optimization (before codigng).
omginternets 4y ago
I find that big-O is exactly the performance problem that remains after you've tuned your IO, picked sensible timeouts, and eliminated deadlocks (which are straight-up bugs). The things you list are the low-hanging fruit, after which most engineering teams throw their arms up and say "I guess we've gone as far as we can on this!"
- UK-AL 4y ago
  It means you're mostly compute limited. Which i find is rare in web api's.
cultofmetatron 4y ago
Big O can mean a lot of things. People often only think of BigO in terms of cpu cycles but it can be applied to memory and network just as easily. Consider a piece of code that grabs a set of records and then loops over them to get an association for each one. I've seen this kind of code in code reviews from juniors. its a good starting point where I start showing them how to rewrite their sql call to get the associated record via join so it goes from O(n) network calls to O(1)
- UK-AL 4y ago
  I find that problem kind of rare these days. Everybody knows about it.

by UK-AL 4y ago

eyelidlessness 4y ago

I work on an application with some serious performance issues. Nearly all of them involve some combination of: - inefficient design around data dependencies and their identification - redundant work performed around said dependencies - excessive reliance on APIs for uses they’re not intended, which frequently causes… - …excessive VM deoptimizations and excessive GC Granted this is one application and I certainly don’t think it’s representative of anything. But it’s definitely a counterpoint to inefficient concurrency (where this app generally performs quite well).

trashtester 4y ago

Knowing WHEN to do BigO optimizations is part of knowing how to optimize. And for cases that _could_ ble NlogN, it may be perfectly fine to chose N^2 for moderate N, while N^3 can kill the solution. As for timeouts, IO and deadlocks, those problems can also be a case of poor up front optimization (before codigng).

omginternets 4y ago

I find that big-O is exactly the performance problem that remains after you've tuned your IO, picked sensible timeouts, and eliminated deadlocks (which are straight-up bugs). The things you list are the low-hanging fruit, after which most engineering teams throw their arms up and say "I guess we've gone as far as we can on this!"

UK-AL 4y ago
It means you're mostly compute limited. Which i find is rare in web api's.

cultofmetatron 4y ago

Big O can mean a lot of things. People often only think of BigO in terms of cpu cycles but it can be applied to memory and network just as easily. Consider a piece of code that grabs a set of records and then loops over them to get an association for each one. I've seen this kind of code in code reviews from juniors. its a good starting point where I start showing them how to rewrite their sql call to get the associated record via join so it goes from O(n) network calls to O(1)

UK-AL 4y ago
I find that problem kind of rare these days. Everybody knows about it.