premature-optimization

Due to the wonders of branch prediction, a binary search can be slower than a linear search through an array of integers. On a typical desktop processor, how big does that array have to get before it would be better to use a binary search? Assume the structure will be used for many lookups. Alex Martelli I've tried a little C++ benchmarking and I'm surprised - linear search seems to prevail up to several dozen items, and I haven't found a case where binary search is better for those sizes. Maybe gcc's STL is not well tuned? But then -- what would you use to implement either kind of search?-)

I have something like this: Map<String, String> myMap = ...; for(String key : myMap.keySet()) { System.out.println(key); System.out.println(myMap.get(key)); } So is myMap.keySet() called once in the foreach loop ? I think it is, but want your opinion. I would like to know if using foreach in this way ( myMap.keySet() ) has a performance impact or it is equivalent to this: Set<String> keySet = myMap.keySet(); for (String key : keySet) { ... } Eddie If you want to be absolutely certain, then compile it both ways and decompile it and compare. I did this with the following source: public void test

I read on a site that using xor swaps is fast because it doesn't use a temporary variable. Here's an example: #include <stdio.h> int main(void) { int a=234,b=789; b=b^a; a=b^a; b=b^a; printf("a=%d,b=%d",a,b); return 0; } Why don't people use this technique in real life code? Is it just poor style? Is there something not well defined about it? Is it an optimisation that my compiler might produce from more clear code, automatically? Because readability is preferred over performance. Because tmp = a; a = b; b = tmp; is not that slow. Because the compiler will optimize it anyway. Because it works

In java I usually make a for-loop like following: for (int i = 0; i < max; i++) { something } But recently a colleague typed it so: for (int i = 0; i < max; ++i) { something } He said the latter would be faster. Is that true? No, it's not true. You could measure the performance by timing each loop for a large number of iterations, but I'm fairly certain they will be the same. The myth came from C where ++i was regarded as faster than i++ because the former can be implemented by incremeting i then returning it. The latter might be implemented by copying the value of i to a temporary variable,

There are two types of if statements in java - classic: if {} else {} and shorthand: exp ? value1 : value2 . Is one faster than the other or are they the same? statement: int x; if (expression) { x = 1; } else { x = 2; } ternary operator: int x = (expression) ? 1 : 2; There's only one type of "if" statement there. The other is a conditional expression. As to which will perform better: they could compile to the same bytecode, and I would expect them to behave identically - or so close that you definitely wouldn't want to choose one over the other in terms of performance. Sometimes an if

Is there any performance benefit one way or another? Is it compiler/VM specific? I am using Hotspot. First: you shouldn't be making the choice of static vs non-static on the basis of performance. Second: in practice, it won't make any difference. Hotspot may choose to optimize in ways that make static calls faster for one method, non-static calls faster for another. Third: much of the mythos surrounding static versus non-static are based either on very old JVMs (which did not do anywhere near the optimization that Hotspot does), or some remembered trivia about C++ (in which a dynamic call uses