Search Results

Search found 2 results on 1 pages for 'rotsor'.

Page 1/1 | 1 

  • Why is Dictionary.First() so slow?

    - by Rotsor
    Not a real question because I already found out the answer, but still interesting thing. I always thought that hash table is the fastest associative container if you hash properly. However, the following code is terribly slow. It executes only about 1 million iterations and takes more than 2 minutes of time on a Core 2 CPU. The code does the following: it maintains the collection todo of items it needs to process. At each iteration it takes an item from this collection (doesn't matter which item), deletes it, processes it if it wasn't processed (possibly adding more items to process), and repeats this until there are no items to process. The culprit seems to be the Dictionary.Keys.First() operation. The question is why is it slow? Stopwatch watch = new Stopwatch(); watch.Start(); HashSet<int> processed = new HashSet<int>(); Dictionary<int, int> todo = new Dictionary<int, int>(); todo.Add(1, 1); int iterations = 0; int limit = 500000; while (todo.Count > 0) { iterations++; var key = todo.Keys.First(); var value = todo[key]; todo.Remove(key); if (!processed.Contains(key)) { processed.Add(key); // process item here if (key < limit) { todo[key + 13] = value + 1; todo[key + 7] = value + 1; } // doesn't matter much how } } Console.WriteLine("Iterations: {0}; Time: {1}.", iterations, watch.Elapsed); This results in: Iterations: 923007; Time: 00:02:09.8414388. Simply changing Dictionary to SortedDictionary yields: Iterations: 499976; Time: 00:00:00.4451514. 300 times faster while having only 2 times less iterations. The same happens in java. Used HashMap instead of Dictionary and keySet().iterator().next() instead of Keys.First().

    Read the article

  • Odd C++ template behaviour with static member vars

    - by jon hanson
    This piece of code is supposed to calculate an approximation to e (i.e. the mathematical constant ~ 2.71828183) at compile-time, using the following approach; e1 = 2 / 1 e2 = (2 * 2 + 1) / (2 * 1) = 5 / 2 = 2.5 e3 = (3 * 5 + 1) / (3 * 2) = 16 / 6 ~ 2.67 e4 = (4 * 16 + 1) / (4 * 6) = 65 / 24 ~ 2.708 ... e(i) = (e(i-1).numer * i + 1) / (e(i-1).denom * i) The computation is returned via the result static member however, after 2 iterations it yields zero instead of the expected value. I've added a static member function f() to compute the same value and that doesn't exhibit the same problem. #include <iostream> #include <iomanip> // Recursive case. template<int ITERS, int NUMERATOR = 2, int DENOMINATOR = 1, int I = 2> struct CalcE { static const double result; static double f () {return CalcE<ITERS, NUMERATOR * I + 1, DENOMINATOR * I, I + 1>::f ();} }; template<int ITERS, int NUMERATOR, int DENOMINATOR, int I> const double CalcE<ITERS, NUMERATOR, DENOMINATOR, I>::result = CalcE<ITERS, NUMERATOR * I + 1, DENOMINATOR * I, I + 1>::result; // Base case. template<int ITERS, int NUMERATOR, int DENOMINATOR> struct CalcE<ITERS, NUMERATOR, DENOMINATOR, ITERS> { static const double result; static double f () {return result;} }; template<int ITERS, int NUMERATOR, int DENOMINATOR> const double CalcE<ITERS, NUMERATOR, DENOMINATOR, ITERS>::result = static_cast<double>(NUMERATOR) / DENOMINATOR; // Test it. int main (int argc, char* argv[]) { std::cout << std::setprecision (8); std::cout << "e2 ~ " << CalcE<2>::result << std::endl; std::cout << "e3 ~ " << CalcE<3>::result << std::endl; std::cout << "e4 ~ " << CalcE<4>::result << std::endl; std::cout << "e5 ~ " << CalcE<5>::result << std::endl; std::cout << std::endl; std::cout << "e2 ~ " << CalcE<2>::f () << std::endl; std::cout << "e3 ~ " << CalcE<3>::f () << std::endl; std::cout << "e4 ~ " << CalcE<4>::f () << std::endl; std::cout << "e5 ~ " << CalcE<5>::f () << std::endl; return 0; } I've tested this with VS 2008 and VS 2010, and get the same results in each case: e2 ~ 2 e3 ~ 2.5 e4 ~ 0 e5 ~ 0 e2 ~ 2 e3 ~ 2.5 e4 ~ 2.6666667 e5 ~ 2.7083333 Why does result not yield the expected values whereas f() does? According to Rotsor's comment below, this does work with GCC, so I guess the question is, am i relying on some type of undefined behaviour with regards to static initialisation order, or is this a bug with Visual Studio?

    Read the article

1