Is it possible to divide an unsigned integer by 10 by using pure bit shifts, addition, subtraction and *maybe* multiply?  Using a processor with very limited resources and slow divide.

Divide by 10 using bit shifts?

I wrote two methods to check there performance

     public class Test1 {

     private String value;

     public void notNull(){
      if( value != null) {
        //do something
      }
    }

    public void nullNot(){
     if( null != value) {
      //do something
     }
    }

    }

and checked it&#39;s byte code after compiling

    public void notNull();
    Code:
    Stack=1, Locals=1, Args_size=1
    0: aload_0
    1: getfield #2; //Field value:Ljava/lang/String;
    4: ifnull 7
    7: return
    LineNumberTable: 
    line 6: 0
    line 9: 7

    StackMapTable: number_of_entries = 1
    frame_type = 7 /* same */


    public void nullNot();
    Code:
    Stack=2, Locals=1, Args_size=1
    0: aconst_null
    1: aload_0
    2: getfield #2; //Field value:Ljava/lang/String;
    5: if_acmpeq 8
    8: return
    LineNumberTable: 
    line 12: 0
    line 15: 8

    StackMapTable: number_of_entries = 1
    frame_type = 8 /* same */


    }


in here two opcodes are used to implement the if condition: in first case it use ifnull- check top value of stack is null-, and in second case it use if_acmpeq- check top two value are equal in the stack-

so, will this make an effect on performance?
(this will helps me to prove first implementation of null is good in performance wise as well as in the aspect of readability :) )



&#39; ... != null&#39; or &#39;null != ....&#39; best performance?

What is the difference between the `enter` and
    
    push ebp
    mov  ebp, esp
    sub  esp, imm

instructions? Is there a performence difference? If so, which is faster and why do compilers always use the latter?

Similarily with the `leave` and

    mov  esp, ebp
    pop  ebp

instructions.

&quot;enter&quot; vs &quot;push ebp; mov ebp, esp; sub esp, imm&quot; and &quot;leave&quot; vs &quot;mov esp, ebp; pop ebp&quot;

I was testing some code on Visual Studio 2008 and noticed `security_cookie`. I can understand the point of it, but I don&#39;t understand what the purpose of this instruction is.

        rep ret /* REP to avoid AMD branch prediction penalty */

Of course I can understand the comment :) but what is this prefix exaclty doing in context with the `ret` and what happens if `ecx` is != 0? Apparently the loop count from `ecx` is ignored when I debug it, which is to be expected.

The code where I found this was here (injected by the compiler for security):

	void __declspec(naked) __fastcall __security_check_cookie(UINT_PTR cookie)
	{
		/* x86 version written in asm to preserve all regs */
		__asm {
			cmp ecx, __security_cookie
			jne failure
			rep ret /* REP to avoid AMD branch prediction penalty */
	failure:
			jmp __report_gsfailure
		}
	}


What does `rep ret` mean?

We have to build Strings all the time for log output and so on. Over the JDK versions we have learned when to use `StringBuffer` (many appends, thread safe) and `StringBuilder` (many appends, non-thread-safe).

What&#39;s the advice on using `String.format()`? Is it efficient, or are we forced to stick with concatenation for one-liners where performance is important?

e.g. ugly old style,

    String s = &quot;What do you get if you multiply &quot; + varSix + &quot; by &quot; + varNine + &quot;?&quot;;

vs. tidy new style (String.format, which is possibly slower),

    String s = String.format(&quot;What do you get if you multiply %d by %d?&quot;, varSix, varNine);

Note: my specific use case is the hundreds of &#39;one-liner&#39; log strings throughout my code. They don&#39;t involve a loop, so `StringBuilder` is too heavyweight. I&#39;m interested in `String.format()` specifically.

Should I use Java&#39;s String.format() if performance is important?

All the following instructions do the same thing: set `%eax` to zero. Which way is optimal (requiring fewest machine cycles)?

    xorl   %eax, %eax
    mov    $0, %eax
    andl   $0, %eax


What is the best way to set a register to zero in x86 assembly: xor, mov or and?

In [another question][1], the accepted answer suggested replacing a (very cheap) if statement in Python code with a try/except block to improve performance.

Coding style issues aside, and assuming that the exception is never triggered, how much difference does it make (performance-wise) to have an exception handler, versus not having one, versus having a compare-to-zero if-statement?


  [1]: https://stackoverflow.com/questions/2521558/avoid-if-statement-after-condition-has-been-met

Cost of exception handlers in Python

This question is merely for me as I always like to write optimized code that can run also on cheap slow servers (or servers with A LOT of traffic)

I looked around and I was not able to find an answer.  I was wondering what is faster between those two examples keeping in mind that the array&#39;s keys in my case are not important (pseudo-code naturally):

    &lt;?php
    $a = array();
    while($new_val = &#39;get over 100k email addresses already lowercased&#39;){
        if(!in_array($new_val, $a){
            $a[] = $new_val;
            //do other stuff
        }
    }
    ?&gt;
    
    &lt;?php
    $a = array();
    while($new_val = &#39;get over 100k email addresses already lowercased&#39;){
        if(!isset($a[$new_val]){
            $a[$new_val] = true;
            //do other stuff
        }
    }
    ?&gt;

As the point of the question is not the array collision, I would like to add that if you are afraid of colliding inserts for `$a[$new_value]`, you can use `$a[md5($new_value)]`.  it can still cause collisions, but would take away from a possible DoS attack when reading from an user provided file (http://nikic.github.com/2011/12/28/Supercolliding-a-PHP-array.html)

what is faster: in_array or isset?

I&#39;ve got a performance critical binary decision tree, and I&#39;d like to focus this question on a single line of code. The code for the binary tree iterator is below with the results from running performance analysis against it.

            public ScTreeNode GetNodeForState(int rootIndex, float[] inputs)
            {
    0.2%        ScTreeNode node = RootNodes[rootIndex].TreeNode;

    24.6%       while (node.BranchData != null)
                {
    0.2%            BranchNodeData b = node.BranchData;
    0.5%            node = b.Child2;
    12.8%           if (inputs[b.SplitInputIndex] &lt;= b.SplitValue)
    0.8%                node = b.Child1;
                }

    0.4%        return node;
            }

**BranchData is a field, not a property.** I did this to prevent the risk of it not being inlined.

The BranchNodeData class is as follows:

    public sealed class BranchNodeData
    {
        /// &lt;summary&gt;
        /// The index of the data item in the input array on which we need to split
        /// &lt;/summary&gt;
        internal int SplitInputIndex = 0;

        /// &lt;summary&gt;
        /// The value that we should split on
        /// &lt;/summary&gt;
        internal float SplitValue = 0;

        /// &lt;summary&gt;
        /// The nodes children
        /// &lt;/summary&gt;
        internal ScTreeNode Child1;
        internal ScTreeNode Child2;
    }

As you can see, the while loop / null check is a massive hit on performance. The tree is massive, so I would expect searching for a leaf to take a while, but I&#39;d like to understand the disproportionate amount of time spent on that one line.

I&#39;ve tried:

 - Separating the Null check from the while - it&#39;s the Null check that&#39;s the hit.
 - Adding a boolean field to the object and checking against that, it made no difference. It doesn&#39;t matter what&#39;s being compared, it&#39;s the comparison that&#39;s the issue.

Is this a branch prediction issue? If so, what can I do about it? If anything?

I won&#39;t pretend to understand the [CIL][1], but I&#39;ll post it for anyone does so they can try to scrape some information from it.

    .method public hidebysig
    instance class OptimalTreeSearch.ScTreeNode GetNodeForState (
        int32 rootIndex,
        float32[] inputs
    ) cil managed
    {
        // Method begins at RVA 0x2dc8
        // Code size 67 (0x43)
        .maxstack 2
        .locals init (
            [0] class OptimalTreeSearch.ScTreeNode node,
            [1] class OptimalTreeSearch.BranchNodeData b
        )

        IL_0000: ldarg.0
        IL_0001: ldfld class [mscorlib]System.Collections.Generic.List`1&lt;class OptimalTreeSearch.ScRootNode&gt; OptimalTreeSearch.ScSearchTree::RootNodes
        IL_0006: ldarg.1
        IL_0007: callvirt instance !0 class [mscorlib]System.Collections.Generic.List`1&lt;class OptimalTreeSearch.ScRootNode&gt;::get_Item(int32)
        IL_000c: ldfld class OptimalTreeSearch.ScTreeNode OptimalTreeSearch.ScRootNode::TreeNode
        IL_0011: stloc.0
        IL_0012: br.s IL_0039
        // loop start (head: IL_0039)
            IL_0014: ldloc.0
            IL_0015: ldfld class OptimalTreeSearch.BranchNodeData OptimalTreeSearch.ScTreeNode::BranchData
            IL_001a: stloc.1
            IL_001b: ldloc.1
            IL_001c: ldfld class OptimalTreeSearch.ScTreeNode OptimalTreeSearch.BranchNodeData::Child2
            IL_0021: stloc.0
            IL_0022: ldarg.2
            IL_0023: ldloc.1
            IL_0024: ldfld int32 OptimalTreeSearch.BranchNodeData::SplitInputIndex
            IL_0029: ldelem.r4
            IL_002a: ldloc.1
            IL_002b: ldfld float32 OptimalTreeSearch.BranchNodeData::SplitValue
            IL_0030: bgt.un.s IL_0039

            IL_0032: ldloc.1
            IL_0033: ldfld class OptimalTreeSearch.ScTreeNode OptimalTreeSearch.BranchNodeData::Child1
            IL_0038: stloc.0

            IL_0039: ldloc.0
            IL_003a: ldfld class OptimalTreeSearch.BranchNodeData OptimalTreeSearch.ScTreeNode::BranchData
            IL_003f: brtrue.s IL_0014
        // end loop

        IL_0041: ldloc.0
        IL_0042: ret
    } // end of method ScSearchTree::GetNodeForState

**Edit:** I decided to do a branch prediction test, I added an identical if within the while, so we have

    while (node.BranchData != null)

and

    if (node.BranchData != null)

inside that. I then ran performance analysis against that, and it took six times longer to execute the first comparison as it did to execute the second comparison that always returned true. So it looks like it is indeed a branch prediction issue - and I&#39;m guessing there&#39;s nothing I can do about it?!

**Another Edit**

The above result would also occur if node.BranchData had to be loaded from the RAM for the while check - it would then be cached for the if statement.

&lt;hr/&gt;

This is my third question on a similar topic. This time I&#39;m focusing on a single line of code.
My other questions on this subject are:

 - https://stackoverflow.com/questions/16539564/could-i-use-a-faster-data-structure-than-a-tree-for-this
 - https://stackoverflow.com/questions/16416084/micro-optimisations-iterating-through-a-tree-in-c-sharp


  [1]: http://en.wikipedia.org/wiki/Common_Intermediate_Language


Why does my application spend 24% of its life doing a null check?

I&#39;ve been trying to optimize some extremely performance-critical code (a quick sort algorithm that&#39;s being called millions and millions of times inside a monte carlo simulation) by loop unrolling.  Here&#39;s the inner loop I&#39;m trying to speed up:

    // Search for elements to swap.
    while(myArray[++index1] &lt; pivot) {}
    while(pivot &lt; myArray[--index2]) {}

I tried unrolling to something like:

    while(true) {
        if(myArray[++index1] &lt; pivot) break;
        if(myArray[++index1] &lt; pivot) break;
        // More unrolling
    }
    
    
    while(true) {
        if(pivot &lt; myArray[--index2]) break;
        if(pivot &lt; myArray[--index2]) break;
        // More unrolling
    }

This made absolutely no difference so I changed it back to the more readable form.  I&#39;ve had similar experiences other times I&#39;ve tried loop unrolling.  Given the quality of branch predictors on modern hardware, when, if ever, is loop unrolling still a useful optimization?

When, if ever, is loop unrolling still useful?

Is there any (non-microoptimization) performance gain by coding

    float f1 = 200f / 2

in comparision to

    float f2 = 200f * 0.5

A professor of mine told me a few years ago that floating point divisions were slower than floating point multiplications without elaborating the why.

Does this statement hold for modern PC architecture?

**Update1**

In respect to a comment, please do also consider this case:


    float f1;
    float f2 = 2
    float f3 = 3;
    for( i =0 ; i &lt; 1e8; i++)
    {
      f1 = (i * f2 + i / f3) * 0.5; //or divide by 2.0f, respectively
    }


**Update 2**
Quoting from the comments:

&gt; [I want] to know what are the algorithmic / architectural requirements that cause &gt; division to be vastly more complicated in hardware than multiplication


Floating point division vs floating point multiplication

A colleague showed me code that I thought wouldn&#39;t be necessary, but sure enough, it was. I would expect most compilers would see all three of these attempts at equality tests as equivalent:

```
#include &lt;cstdint&gt;
#include &lt;cstring&gt;

struct Point {
    std::int32_t x, y;
};

[[nodiscard]]
bool naiveEqual(const Point &amp;a, const Point &amp;b) {
    return a.x == b.x &amp;&amp; a.y == b.y;
}

[[nodiscard]]
bool optimizedEqual(const Point &amp;a, const Point &amp;b) {
    // Why can&#39;t the compiler produce the same assembly in naiveEqual as it does here?
    std::uint64_t ai, bi;
    static_assert(sizeof(Point) == sizeof(ai));
    std::memcpy(&amp;ai, &amp;a, sizeof(Point));
    std::memcpy(&amp;bi, &amp;b, sizeof(Point));
    return ai == bi;
}

[[nodiscard]]
bool optimizedEqual2(const Point &amp;a, const Point &amp;b) {
    return std::memcmp(&amp;a, &amp;b, sizeof(a)) == 0;
}


[[nodiscard]]
bool naiveEqual1(const Point &amp;a, const Point &amp;b) {
    // Let&#39;s try avoiding any jumps by using bitwise and:
    return (a.x == b.x) &amp; (a.y == b.y);
}
```

But to my surprise, only the ones with `memcpy` or `memcmp` get turned into a single 64-bit compare by GCC. Why?  (https://godbolt.org/z/aP1ocs)

Isn&#39;t it obvious to the optimizer that if I check equality on contiguous pairs of four bytes that that&#39;s the same as comparing on all eight bytes?

An attempt to avoid separately booleanizing the two parts compiles somewhat more efficiently (one fewer instruction and no false dependency on EDX), but still two separate 32-bit operations.

```
bool bithackEqual(const Point &amp;a, const Point &amp;b) {
    // a^b == 0 only if they&#39;re equal
    return ((a.x ^ b.x) | (a.y ^ b.y)) == 0;
}
```

---

GCC and Clang both have the same missed optimizations when passing the structs by *value* (so `a` is in RDI and `b` is in RSI because that&#39;s how x86-64 System V&#39;s calling convention packs structs into registers): https://godbolt.org/z/v88a6s.  The memcpy / memcmp versions both compile to `cmp  rdi, rsi`  / `sete  al`, but the others do separate 32-bit operations.

`struct alignas(uint64_t) Point` surprisingly still helps in the by-value case where arguments are in registers, optimizing both naiveEqual versions for GCC, but not the bithack XOR/OR.  (https://godbolt.org/z/ofGa1f). Does this give us any hints about GCC&#39;s internals? Clang isn&#39;t helped by alignment.





Why can&#39;t GCC generate an optimal operator== for a struct of two int32s?

What is the fastest way to strip all non-printable characters from a `String` in Java?

So far I&#39;ve tried and measured on 138-byte, 131-character String:

* String&#39;s `replaceAll()` - **slowest method**
 * 517009 results / sec
* Precompile a Pattern, then use Matcher&#39;s `replaceAll()`
 * 637836 results / sec
* Use StringBuffer, get codepoints using `codepointAt()` one-by-one and append to StringBuffer
 * 711946 results / sec
* Use StringBuffer, get chars using `charAt()` one-by-one and append to StringBuffer
 * 1052964 results / sec
* Preallocate a `char[]` buffer, get chars using `charAt()` one-by-one and fill this buffer, then convert back to String
 * 2022653 results / sec
* Preallocate 2 `char[]` buffers - old and new, get all chars for existing String at once using `getChars()`, iterate over old buffer one-by-one and fill new buffer, then convert new buffer to String - **my own fastest version**
 * 2502502 results / sec
* Same stuff with 2 buffers - only using `byte[]`, `getBytes()` and specifying encoding as &quot;utf-8&quot;
 * 857485 results / sec
* Same stuff with 2 `byte[]` buffers, but specifying encoding as a constant `Charset.forName(&quot;utf-8&quot;)`
 * 791076 results / sec
* Same stuff with 2 `byte[]` buffers, but specifying encoding as 1-byte local encoding (barely a sane thing to do)
 * 370164 results / sec

My best try was the following:

        char[] oldChars = new char[s.length()];
        s.getChars(0, s.length(), oldChars, 0);
        char[] newChars = new char[s.length()];
        int newLen = 0;
        for (int j = 0; j &lt; s.length(); j++) {
            char ch = oldChars[j];
            if (ch &gt;= &#39; &#39;) {
                newChars[newLen] = ch;
                newLen++;
            }
        }
        s = new String(newChars, 0, newLen);

Any thoughts on how to make it even faster?

Bonus points for answering a very strange question: why using &quot;utf-8&quot; charset name directly yields better performance than using pre-allocated static const `Charset.forName(&quot;utf-8&quot;)`?

# Update #

* Suggestion from *ratchet freak* yields impressive 3105590 results / sec performance, a +24% improvement!
* Suggestion from *Ed Staub* yields yet another improvement - 3471017 results / sec, a +12% over previous best.

# Update 2 #

I&#39;ve tried my best to collected all the proposed solutions and its cross-mutations and published it as a [small benchmarking framework at github][gh]. Currently it sports 17 algorithms. One of them is &quot;special&quot; - *Voo1* algorithm ([provided by SO user Voo][voo1]) employs intricate reflection tricks thus achieving stellar speeds, but it messes up JVM strings&#39; state, thus it&#39;s benchmarked separately.

You&#39;re welcome to check it out and run it to determine results on your box. Here&#39;s a summary of results I&#39;ve got on mine. It&#39;s specs:

* Debian sid
* Linux 2.6.39-2-amd64 (x86_64)
* Java installed from a package `sun-java6-jdk-6.24-1`, JVM identifies itself as
 * Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
 * Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

Different algorithms show ultimately different results given a different set of input data. I&#39;ve ran a benchmark in 3 modes:

## Same single string ##

This mode works on a same single string provided by `StringSource` class as a constant. The showdown is:

&lt;pre&gt;
 Ops / s  │ Algorithm
──────────┼──────────────────────────────
6 535 947 │ Voo1
──────────┼──────────────────────────────
5 350 454 │ RatchetFreak2EdStaub1GreyCat1
5 249 343 │ EdStaub1
5 002 501 │ EdStaub1GreyCat1
4 859 086 │ ArrayOfCharFromStringCharAt
4 295 532 │ RatchetFreak1
4 045 307 │ ArrayOfCharFromArrayOfChar
2 790 178 │ RatchetFreak2EdStaub1GreyCat2
2 583 311 │ RatchetFreak2
1 274 859 │ StringBuilderChar
1 138 174 │ StringBuilderCodePoint
  994 727 │ ArrayOfByteUTF8String
  918 611 │ ArrayOfByteUTF8Const
  756 086 │ MatcherReplace
  598 945 │ StringReplaceAll
  460 045 │ ArrayOfByteWindows1251
&lt;/pre&gt;

In charted form:
[![Same single string chart][1]][1]  
&lt;sub&gt;(source: [greycat.ru](http://www.greycat.ru/img/os-chart-single.png))&lt;/sub&gt;  


## Multiple strings, 100% of strings contain control characters ##

Source string provider pre-generated lots of random strings using (0..127) character set - thus almost all strings contained at least one control character. Algorithms received strings from this pre-generated array in round-robin fashion.

&lt;pre&gt;
 Ops / s  │ Algorithm
──────────┼──────────────────────────────
2 123 142 │ Voo1
──────────┼──────────────────────────────
1 782 214 │ EdStaub1
1 776 199 │ EdStaub1GreyCat1
1 694 628 │ ArrayOfCharFromStringCharAt
1 481 481 │ ArrayOfCharFromArrayOfChar
1 460 067 │ RatchetFreak2EdStaub1GreyCat1
1 438 435 │ RatchetFreak2EdStaub1GreyCat2
1 366 494 │ RatchetFreak2
1 349 710 │ RatchetFreak1
  893 176 │ ArrayOfByteUTF8String
  817 127 │ ArrayOfByteUTF8Const
  778 089 │ StringBuilderChar
  734 754 │ StringBuilderCodePoint
  377 829 │ ArrayOfByteWindows1251
  224 140 │ MatcherReplace
  211 104 │ StringReplaceAll
&lt;/pre&gt;
In charted form:
[![Multiple strings, 100% concentration][2]][2]  
&lt;sub&gt;(source: [greycat.ru](http://www.greycat.ru/img/os-chart-multi100.png))&lt;/sub&gt;  


## Multiple strings, 1% of strings contain control characters ##

Same as previous, but only 1% of strings was generated with control characters - other 99% was generated in using [32..127] character set, so they couldn&#39;t contain control characters at all. This synthetic load comes the closest to real world application of this algorithm at my place.

&lt;pre&gt;
 Ops / s  │ Algorithm
──────────┼──────────────────────────────
3 711 952 │ Voo1
──────────┼──────────────────────────────
2 851 440 │ EdStaub1GreyCat1
2 455 796 │ EdStaub1
2 426 007 │ ArrayOfCharFromStringCharAt
2 347 969 │ RatchetFreak2EdStaub1GreyCat2
2 242 152 │ RatchetFreak1
2 171 553 │ ArrayOfCharFromArrayOfChar
1 922 707 │ RatchetFreak2EdStaub1GreyCat1
1 857 010 │ RatchetFreak2
1 023 751 │ ArrayOfByteUTF8String
  939 055 │ StringBuilderChar
  907 194 │ ArrayOfByteUTF8Const
  841 963 │ StringBuilderCodePoint
  606 465 │ MatcherReplace
  501 555 │ StringReplaceAll
  381 185 │ ArrayOfByteWindows1251
&lt;/pre&gt;

In charted form:
[![Multiple strings, 1% concentration][3]][3]  
&lt;sub&gt;(source: [greycat.ru](http://www.greycat.ru/img/os-chart-multi1.png))&lt;/sub&gt;  


It&#39;s very hard for me to decide on who provided the best answer, but given the real-world application best solution was given/inspired by Ed Staub, I guess it would be fair to mark his answer. Thanks for all who took part in this, your input was very helpful and invaluable. Feel free to run the test suite on your box and propose even better solutions (working JNI solution, anyone?).

## References ##

* [GitHub repository][gh] with a benchmarking suite

  [gh]: https://github.com/GreyCat/java-string-benchmark
  [voo1]: https://stackoverflow.com/questions/7161534/fastest-way-to-strip-all-non-printable-characters-from-a-java-string/7175771#7175771
 [1]: https://i.stack.imgur.com/5n8k5.png
 [2]: https://i.stack.imgur.com/JogeX.png
 [3]: https://i.stack.imgur.com/TnQAd.png

Fastest way to strip all non-printable characters from a Java String

Which of the following techniques is the best option for dividing an integer by 2 and why?

Technique 1:

    x = x &gt;&gt; 1;

Technique 2:

    x = x / 2;

Here `x` is an integer.

Which is better option to use for dividing an integer number by 2?

I stumbled upon this piece of code in .NET&#39;s [List source code](http://referencesource.microsoft.com/#mscorlib/system/collections/generic/list.cs,189):

    // Following trick can reduce the range check by one
    if ((uint) index &gt;= (uint)_size) {
      ThrowHelper.ThrowArgumentOutOfRangeException();
    }

Apparently this is more efficient (?) than `if (index &lt; 0 || index &gt;= _size)`

I am curious about the rationale behind the trick. Is a single branch instruction really more expensive than two conversions to `uint`? Or is there some other optimization going on that will make this code faster than an additional numeric comparison?

*To address the elephant in the room: yes, this is  micro optimization, no I do not intend to use this everywhere in my code – I&#39;m just curious ;)*

Is it more efficient to perform a range check by casting to uint instead of checking for negative values?

Just to make it clear, I&#39;m not going for any sort of portability here, so any solutions that will tie me to a certain box is fine.

Basically, I have an if statement that will 99% of the time evaluate to true, and am trying to eke out every last clock of performance, can I issue some sort of compiler command (using GCC 4.1.2 and the x86 ISA, if it matters) to tell the branch predictor that it should cache for that branch?

Is it possible to tell the branch predictor how likely it is to follow the branch?

I always assumed caching the length of an array in JavaScript is a good idea (especially in the condition of a `for` loop) because of the expensiveness of calculating the length of an array.

### Example

    for (var i = 0; i &lt; arr.length; i++) { }
    
    // vs
    
    for (var i = 0, arrLength = arr.length; i &lt; arrLength; i++) { }


However, I thought perhaps the `length` property is only updated on creation and alteration of the array. Therefore, reading it shouldn&#39;t be too expensive an operation as opposed to reading it stored in a variable (as opposed to other methods in other languages that may need to seek in memory to find the end of something, e.g. `strlen()` in C).

I have two questions. I am also interested in how this works, so please don&#39;t hit me with the *premature optimisation* stick.

Assume the JavaScript engines in browsers.

1. Is there any advantage to caching the `length` property of an array in JavaScript? Is there much more involved in reading a local variable over an object&#39;s property?
2. Is the `length` property simply altered on creation and on `shift()` and `pop()` type methods that don&#39;t return a new array and otherwise simply stored as an integer?



Is reading the `length` property of an array really that expensive an operation in JavaScript?

## Overview

I have an image buffer that I need to convert to another format.  The origin image buffer is four channels, 8 bits per channel, Alpha, Red, Green, and Blue.  The destination buffer is three channels, 8 bits per channel, Blue, Green, and Red.

So the brute force method is:

    // Assume a 32 x 32 pixel image
    #define IMAGESIZE (32*32)

    typedef struct{ UInt8 Alpha; UInt8 Red; UInt8 Green; UInt8 Blue; } ARGB;
    typedef struct{ UInt8 Blue; UInt8 Green; UInt8 Red; } BGR;

    ARGB orig[IMAGESIZE];
    BGR  dest[IMAGESIZE];

    for(x = 0; x &lt; IMAGESIZE; x++)
    {
         dest[x].Red = orig[x].Red;
         dest[x].Green = orig[x].Green;
         dest[x].Blue = orig[x].Blue;
    }

However, I need more speed than is provided by a loop and three byte copies. I&#39;m hoping there might be a few tricks I can use to reduce the number of memory reads and writes, given that I&#39;m running on a 32 bit machine.

## Additional info

Every image is a multiple of at least 4 pixels.  So we could address 16 ARGB bytes and move them into 12 RGB bytes per loop. Perhaps this fact can be used to speed things up, especially as it falls nicely into 32 bit boundaries.

I have access to OpenCL - and while that requires moving the entire buffer into the GPU memory, then moving the result back out, the fact that OpenCL can work on many portions of the image simultaneously, and the fact that large memory block moves are actually quite efficient may make this a worthwhile exploration.

While I&#39;ve given the example of small buffers above, I really am moving HD video (1920x1080) and sometimes larger, mostly smaller, buffers around, so while a 32x32 situation may be trivial, copying 8.3MB of image data byte by byte is really, really bad.

Running on Intel processors (Core 2 and above) and thus there are streaming and data processing commands I&#39;m aware exist, but don&#39;t know about - perhaps pointers on where to look for specialized data handling instructions would be good.

This is going into an OS X application, and I&#39;m using XCode 4.  If assembly is painless and the obvious way to go, I&#39;m fine traveling down that path, but not having done it on this setup before makes me wary of sinking too much time into it.

Pseudo-code is fine - I&#39;m not looking for a complete solution, just the algorithm and an explanation of any trickery that might not be immediately clear.

Fast method to copy memory with translation - ARGB to BGR

There are cases where you know that a certain floating-point expression will always be non-negative. For example, when computing the length of a vector, one does `sqrt(a[0]*a[0] + ... + a[N-1]*a[N-1])` (NB: I *am* aware of `std::hypot`, this is not relevant to the question), and the expression under the square root is clearly non-negative. However, GCC [outputs][1] the following assembly for `sqrt(x*x)`:
```
        mulss   xmm0, xmm0
        pxor    xmm1, xmm1
        ucomiss xmm1, xmm0
        ja      .L10
        sqrtss  xmm0, xmm0
        ret
.L10:
        jmp     sqrtf
```

That is, it compares the result of `x*x` to zero, and if the result is non-negative, it does the `sqrtss` instruction, otherwise it calls `sqrtf`.

So, my question is: **how can I force GCC into assuming that `x*x` is always non-negative so that it skips the comparison and the `sqrtf` call, without writing inline assembly?**

I wish to emphasize that I am interested in a local solution, and not doing things like `-ffast-math`, `-fno-math-errno`, or `-ffinite-math-only` (though these do indeed solve the issue, thanks to ks1322, harold, and Eric Postpischil in the comments).

Furthemore, &quot;force GCC into assuming `x*x` is non-negative&quot; should be interpreted as `assert(x*x &gt;= 0.f)`, so this also excludes the case of `x*x` being NaN.

I am OK with compiler-specific, platform-specific, CPU-specific, etc. solutions.

  [1]: https://godbolt.org/z/SsrYUu

How to force GCC to assume that a floating-point expression is non-negative?

There&#39;re two well-known ways to set an integer register to zero value on x86.

Either

    mov reg, 0

or

    xor reg, reg

There&#39;s an opinion that the second variant is better since the value 0 is not stored in the code and that saves several bytes of produced machine code. This is definitely good - less instruction cache is used and this can sometimes allow for faster code execution. Many compilers produce such code.

However there&#39;s formally an inter-instruction dependency between the xor instruction and whatever earlier instruction that changes the same register. Since there&#39;s a depedency the latter instruction needs to wait until the former completes and this could reduce the processor units load and hurt performance.

    add reg, 17
    ;do something else with reg here
    xor reg, reg

It&#39;s obvious that the result of xor will be exactly the same regardless of the initial register value. But it the processor able to recognize this?

I tried the following test in VC++7:

    const int Count = 10 * 1000 * 1000 * 1000;
    int _tmain(int argc, _TCHAR* argv[])
    {
        int i;
        DWORD start = GetTickCount();
        for( i = 0; i &lt; Count ; i++ ) {
            __asm {
                mov eax, 10
                xor eax, eax
            };
        }
        DWORD diff = GetTickCount() - start;
        start = GetTickCount();
        for( i = 0; i &lt; Count ; i++ ) {
            __asm {
                mov eax, 10
                mov eax, 0
            };
        }
        diff = GetTickCount() - start;
        return 0;
    }

With optimizations off both loops take exactly the same time. Does this reasonably prove that the processor recognizes that there&#39;s no dependency of `xor reg, reg` instruction on the earlier `mov eax, 0` instruction? What could be a better test to check this?

Does using xor reg, reg give advantage over mov reg, 0?

In one of the projects I&#39;m working on, I&#39;m seeing this code

    struct Base {
      virtual ~Base() { }
    };

    struct ClassX {
      bool isHoldingDerivedObj() const {
        return typeid(1 ? *m_basePtr : *m_basePtr) == typeid(Derived);
      }
      Base *m_basePtr;
    };

I have never seen `typeid` used like that. Why does it do that weird dance with `?:`, instead of just doing `typeid(*m_basePtr)`? Could there be any reason? `Base` is a polymorphic class (with a virtual destructor). 

EDIT: At another place of this code, I&#39;m seeing this and it appears to be equivalently &quot;superfluous&quot;

    template&lt;typename T&gt; T &amp;nonnull(T &amp;t) { return t; }

    struct ClassY {
      bool isHoldingDerivedObj() const {
        return typeid(nonnull(*m_basePtr)) == typeid(Derived);
      }
      Base *m_basePtr;
    };



Weird use of `?:` in `typeid` code

What is the fastest way to find if a number is even or odd?

All Micro Optimization Solutions on Gang of Coders

Total of 22 Micro Optimization Solutions