3 ms·

You can profile and application without running it. That's the whole point of BigO notation. The type of profiling your thinking of is a great place to look f

You can profile and application without running it. That's the whole point of BigO notation. The type of profiling your thinking of is a great place to look for less obvious improvements. AKA my N is probaly above 50,000 so (N^N) not worth looking into.

Locke1689 15y ago
Big O is often somewhat useless in practice. Yes, if you have an O(2^n) algorithm that's slow -- don't do that unless you can't approximate and your problem is NP-complete. In most other cases (AKA a good developer usually tries to find O(n)/O(nlog n) algorithms for everything possible) you're really talking about problems due to memory and network. These can never be represented accurately by big-O, so usually it's more accurate to ask in the beginning, "How many RPCs am I doing here?" because that's what's really going to kill you in production.
- onemoreact 15y ago
  I have seen plenty of developers create websites using a lot of O(n^2) code when O(n log n) was an option. Often its simple questions like should I sort this before I do some manipulation and working though which is faster can literally take a few seconds of thought. That's not to say you need to always write optimized code, just avoid writing dumb code when you know it's going to be a problem ahead of time.
  - wanorris 15y ago
    If it's the same amount of work and readability is not sacrificed, consistently using O(n log n) is a good practice for that situation. If the result is more effort or less readable, then an understanding of what n is going to be like is probably worthwhile. For the love of all that's holy, please do not optimize access to a collection of days of the week that is accessed infrequently.
chc 15y ago
Big-O tells you the behavior of your running time as the dataset increases. It does not tell you what parts of your program are actually fast or slow. For example, an O(n^n) algorithm is actually fine if it will never be applied to more than six elements and each operation takes two microseconds, and is vastly better for that case than an O(1) algorithm that takes half a second.

Locke1689 15y ago

Big O is often somewhat useless in practice. Yes, if you have an O(2^n) algorithm that's slow -- don't do that unless you can't approximate and your problem is NP-complete. In most other cases (AKA a good developer usually tries to find O(n)/O(nlog n) algorithms for everything possible) you're really talking about problems due to memory and network. These can never be represented accurately by big-O, so usually it's more accurate to ask in the beginning, "How many RPCs am I doing here?" because that's what's really going to kill you in production.

onemoreact 15y ago
I have seen plenty of developers create websites using a lot of O(n^2) code when O(n log n) was an option. Often its simple questions like should I sort this before I do some manipulation and working though which is faster can literally take a few seconds of thought. That's not to say you need to always write optimized code, just avoid writing dumb code when you know it's going to be a problem ahead of time.
- wanorris 15y ago
  If it's the same amount of work and readability is not sacrificed, consistently using O(n log n) is a good practice for that situation. If the result is more effort or less readable, then an understanding of what n is going to be like is probably worthwhile. For the love of all that's holy, please do not optimize access to a collection of days of the week that is accessed infrequently.

chc 15y ago

Big-O tells you the behavior of your running time as the dataset increases. It does not tell you what parts of your program are actually fast or slow. For example, an O(n^n) algorithm is actually fine if it will never be applied to more than six elements and each operation takes two microseconds, and is vastly better for that case than an O(1) algorithm that takes half a second.