Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>That's the wrong kind of question. The right question would be: "Which one is easier to understand for human readers of my code?"</p> <p>If speed matters (later), don't ask, but measure. (And before that, measure whether optimizing this actually will make any noticeable difference.) Until then, write the code so that it is easiest to read. </p> <p><strong><em>Edit</em></strong><br> Just to make this clear (although it already should have been): Breakthrough speedups usually come from things like <strong><em>using better algorithms</em></strong>, <strong><em>improving locality of data</em></strong>, <strong><em>reducing the use of dynamic memory</em></strong>, <strong><em>pre-computing results</em></strong>, etc. <strong><em>They rarely ever come from micro-optimizing single function calls</em></strong>, and where they do, they do so in <strong><em>very few places</em></strong>, which would only be found by <strong><em>careful</em></strong> (and time-consuming) <strong><em>profiling</em></strong>, more often than never they can be sped up by doing very non-intuitive things (like inserting <code>noop</code> statements), and what's an optimization for one platform is sometimes a pessimization for another (which is why you need to measure, instead of asking, because we don't fully know/have your environment). </p> <p>Let me underline this again: Even in the few applications where such things matter, they don't matter in most places they're used, and <strong>it is <em>very</em> unlikely that you will find the places where they matter by looking at the code.</strong> You really do need to <strong><em>identify the hot spots first</em></strong>, because otherwise optimizing code is just <strong><em>a waste of time</em></strong>. </p> <p>Even if a single operation (like computing the square of some value) takes up <strong><em>10% of the application's execution time</em></strong> (which IME is quite rare), and even if optimizing it saves <strong><em>50% of the time</em></strong> necessary for that operation (which IME is even much, much rarer), you still made the application take <strong><em>only 5% less time</em></strong>.<br> Your users will need a stopwatch to even notice that. (I guess in most cases anything under 20% speedup goes unnoticed for most users. And <em>that</em> is four such spots you need to find.) </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload