6

I have the following working codes (g++ 8.2 , the C++17 standard.)

    queue<TreeNode*> q{};

    q.push(root);
    q.push(nullptr);
    int sum = root -> val;
    while (!q.empty()) {
        TreeNode *n = q.front();
        q.pop();

        if (n != nullptr) {
            sum += n->val;
            if (n-> left != nullptr) q.push(n->left);
            if (n-> right != nullptr) q.push(n->right);   
        } else {
            if (q.empty()) break;
            q.push(nullptr);
            sum = 0;
        }

    }
    return sum;

Then I replaced queue<TreeNode*> with deque<TreeNode*>. It turned out the speed improved at least 20%. Why is deque<TreeNode*> so much faster than queue<TreeNode*>?

Ben Bolker
  • 211,554
  • 25
  • 370
  • 453
Edamame
  • 23,718
  • 73
  • 186
  • 320
  • 2
    Would be helpful if you specify what compiler you used for this finding – Asesh Dec 31 '19 at 10:26
  • 7
    Are you testing a unoptimized debug build or an optimized release build? What are your compiler flags/options? – Jesper Juhl Dec 31 '19 at 10:45
  • 2
    Can you supply the minimum code used to make the timings and the compiler settings used to compile the code? – Galik Dec 31 '19 at 10:49

1 Answers1

15

From cppreference.com: std::queue

template<
    class T,
    class Container = std::deque<T>
> class queue;

Container - The type of the underlying container to use to store the elements.

So std::queue - by default - uses std::deque as its internal container, due to that it can only be at best as fast as std::deque (or the underlying container in general), and because being a wrapper it is - depending on the optimization the compiler can do - slower. So if you correctly measure a 20% slowdown, then you measure how good the compiler is in optimizing the wrapper code away at the given optimization level.

As std::queue exists to guarantee a FIFO usage, by only exposing these functions, I doubt - but I can't test it right now - that the slow down is that drastically with optimizations turned on. If it is I would consider that as a bug/defect of the capabilities of the compiler or library implementation.

t.niese
  • 39,256
  • 9
  • 74
  • 101