Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I imagine the reason why you found iterating and adding to std::vector 3 times slower than a plain array is a combination of the cost of iterating the vector and doing the assigment. </p> <p><strong>Edit:</strong></p> <p>That was my initial assumption before the testcase; however running the testcase (compiled with <code>-O3</code>) shows the converse - std::vector is actually 3 times faster, which surprised me.</p> <p>I can't see how std::vector could be faster (certainly not 3 times faster) than a vanilla array copy - I think there's some optimisation being applied to the std::vector compiled code which isn't happening for the array version.</p> <p>Original benchmark results:</p> <pre><code>$ ./array array: 0.059375 vector: 0.021209 </code></pre> <ul> <li><p>std::vector is 3x faster. Same benchmark again, except add an additional outer loop to run the test iterater loop 1000 times:</p> <p>$ ./array array: 21.7129 vector: 21.6413</p></li> <li><p>std::vector is now ~ the same speed as array.</p></li> </ul> <p><strong>Edit 2</strong></p> <p>Found it! So the problem with your test case is that in the vector case the memory holding the data appears to be already in the CPU cache - either by the way it is initialised, or due to the call to <code>vec.end()</code>. If I 'warm' up the CPU cache before each timing test, I get the same numbers for array and vector:</p> <pre><code>#include &lt;time.h&gt; #include &lt;iostream&gt; #include &lt;vector&gt; int main() { clock_t start,end; std::vector&lt;int&gt; vec(9999999); std::vector&lt;int&gt;::iterator vecIt = vec.begin(); std::vector&lt;int&gt;::iterator vecEnd = vec.end(); // get vec into CPU cache. for (int i = 0; vecIt != vecEnd; i++) { *(vecIt++) = i; } vecIt = vec.begin(); start = clock(); for (int i = 0; vecIt != vecEnd; i++) { *(vecIt++) = i; } end = clock(); std::cout&lt;&lt;"vector: "&lt;&lt;(double)(end-start)/CLOCKS_PER_SEC&lt;&lt;std::endl; int* arr = new int[9999999]; // get arr into CPU cache. for (int i = 0; i &lt; 9999999; i++) { arr[i] = i; } start = clock(); for (int i = 0; i &lt; 9999999; i++) { arr[i] = i; } end = clock(); std::cout&lt;&lt;"array: "&lt;&lt;(double)(end-start)/CLOCKS_PER_SEC&lt;&lt;std::endl; } </code></pre> <p>This gives me the following result:</p> <pre><code>$ ./array vector: 0.020875 array: 0.020695 </code></pre>
    singulars
    1. This table or related slice is empty.
    1. PODynamically allocated arrays or std::vector
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDaveR
    1. USDaveR
    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. PO
      1. This table or related slice is empty.
      1. VTDownMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUndeletion
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    1. COit is also not safe. It doesn't do bounds checking by default.
      singulars
      1. PO
      1. USjalf
    2. CObtw, why all the downvotes?
      singulars
      1. PO
      1. USDaveR
    3. COMaybe it's caching the array addresses in the CPU register which is why further runs are much faster? I tried looping 2 times instead of 1000 and while the first run took 0.06s, the second run took 0.25s
      singulars
      1. PO
      1. USOpt
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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