6 ms·

My understanding of the "premature" part is the fact that without profiling your application in some way, you have no idea apriori where the bottlenecks are. Th

by cpt1138 15y ago

My understanding of the "premature" part is the fact that without profiling your application in some way, you have no idea apriori where the bottlenecks are. This "optimization" is premature in that its cost in w/e metric you want (readability, etc.) is payed and you have no idea about its relative performance cost. For example, after performing this "optimization" you save a few milliseconds but the Mnesia sync between two instances is orders of magnitude more time.

onemoreact 15y ago
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.
frankwiles 15y ago
In general yes, but with enough experience you start to just "know" where the bottlenecks are going to be. For example, if you know your user profile pages are going to be the most used, you focus more pre-optimization effort there rather than on some admin report that will be run monthly. While it's still "pre-optimization" it's a smarter use of time to spend it where it will most likely matter.

by cpt1138 15y ago

onemoreact 15y ago

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.

frankwiles 15y ago

In general yes, but with enough experience you start to just "know" where the bottlenecks are going to be. For example, if you know your user profile pages are going to be the most used, you focus more pre-optimization effort there rather than on some admin report that will be run monthly. While it's still "pre-optimization" it's a smarter use of time to spend it where it will most likely matter.