• Advertisement
Sign in to follow this  

Array vs Vector Discussion :)

This topic is 2647 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I saw someones code at work and wondered why they were using a vector instead of an array since we knew the size, so I almost asked the question on here about speed of access but I pretty much knew the answer anyway.

So this is not a question but to beginners, if you know the size of something before the start of your application, use an array. They are always the fastest, and vectors use an underlying array as well, but they are a lot slower to access.

int array[];
vector<int> vector;

array[i]//not a function call, no stack invoked
vector[i]//function call, stack invoked, variables/stack frame saved

array wins 31ms to 1280 ms

#include <vector>
#include <iostream>
#include <windows.h>
using namespace std;

#define XSIZE 10000000
vector<int> vecNumbers;
int arrayNumbers[XSIZE];
int main()
{
vecNumbers.reserve(10000000);
for(int i = 0; i < XSIZE; i++)
{
vecNumbers.push_back(0);
arrayNumbers[i] = 0;
}

float start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
arrayNumbers[i]++;
}
cout << GetTickCount() - start_time << endl;


start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
vecNumbers[i]++;
}
cout << GetTickCount() - start_time;

system("pause");
return 0;
}






[Edited by - dpadam450 on October 18, 2010 6:01:33 PM]

Share this post


Link to post
Share on other sites
Advertisement
I find those numbers highly suspect unless you compiled in debug mode. The subscript operator will likely be inlined in release.

Share this post


Link to post
Share on other sites
I wouldn't be surprised if the release version just optimized both code blocks out, since they're not really doing anything.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rycross
I find those numbers highly suspect unless you compiled in debug mode. The subscript operator will likely be inlined in release.


Or MSVC in release if SECURE_SCL hasn't been disabled.

Share this post


Link to post
Share on other sites
Well still, how many times do we need to run in debug mode? You still need fast enough debug code.

Release with size = 100,000,000
time = 100ms vs 200ms

yea release is fairly negligible, but if it were a 2D or 3D array/vector it would most likely increase in time gap as well.

Also sometimes people forget to reserve their vectors, so millions of items will be slow if you forget to ask for your vector to be big enough to hold all of those items.

Share this post


Link to post
Share on other sites
The purpose behind a debug build is to catch potential errors. In that case using a raw array rather than a vector is counterproductive since a vector can do nice things like bounds checking. However, there are classes for compile time constant arrays that would do a bit better than vectors performance-wise in release, but do checking in debug, such as boost::array.

Share this post


Link to post
Share on other sites
I haven't messed with boost, any other advantages to boost::array other than bounds checks?

Quote:

since a vector can do nice things like bounds checking


It only does that if you use an iterator though. Maybe .at() checks bounds too?

Share this post


Link to post
Share on other sites
Quote:
Original post by bobofjoe
I wouldn't be surprised if the release version just optimized both code blocks out, since they're not really doing anything.


Yeah, I had to add in an extra cout utilizing the array to avoid it being optimized out by gcc. Gcc didn't seem to want to optimize out the std::vector altogether.

Results on doing the same test on 10000000 elements?

57-60 ms vs 61-64 ms. In other words, basically the same.


I did change the post-increment operator to the pre-increment operator. I suspect that gcc would optimize out the copy and call to operator = for vector, but decided to change it just to be sure.

Quote:
Original post by dpadam450
Well still, how many times do we need to run in debug mode? You still need fast enough debug code.


Debug mode is a concern and one of the reasons EA wrote EASTL (note that they implemented their own containers rather than defaulted to plain arrays), but its still better to go with a vector until you are having a problem. As others have pointed out, part of the point of debug is to make sure you aren't doing things wrong, so using a safe container with a speed hit and runtime checks in debug is preferable to extra speed, unless you're hitting serious bottlenecks.


Quote:
Original post by dpadam450
Also sometimes people forget to reserve their vectors, so millions of items will be slow if you forget to ask for your vector to be big enough to hold all of those items.


If those developers can't use std::vector correctly, what makes you think they'll use raw arrays correctly?

[Edited by - Rycross on October 18, 2010 4:59:58 PM]

Share this post


Link to post
Share on other sites
Quote:

Well still, how many times do we need to run in debug mode? You still need fast enough debug code.

The checks can be disabled in debug mode if you like.


Ok, lets look at the assembly. Here is the source I used:

#include <vector>
#include <cstdio>
#include <windows.h>

using namespace std;

const unsigned int XSIZE = 10000000;

int main()
{
vector<int> vecNumbers;
int arrayNumbers[XSIZE];
vecNumbers.reserve(10000000);
for(int i = 0; i < XSIZE; i++)
{
vecNumbers.push_back(0);
arrayNumbers[i] = 0;
}

DWORD start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
arrayNumbers[i]++;
}
DWORD elapsed = GetTickCount() - start_time;
printf("array: %d\n", elapsed);

start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
vecNumbers[i]++;
}
elapsed = GetTickCount() - start_time;
printf("vector: %d\n", elapsed);

system("pause");
return 0;
}



Assembler output:

; 19 :
; 20 : DWORD start_time = GetTickCount();

mov edi, DWORD PTR __imp__GetTickCount@0
call edi
mov ebx, eax

; 21 : for(int i = 0; i < XSIZE;i++)

xor eax, eax
npad 4
$LL6@main:

; 22 : {
; 23 : arrayNumbers[i]++;

inc DWORD PTR _arrayNumbers$[esp+eax*4+40000056]
inc eax
cmp eax, 10000000 ; 00989680H
jb SHORT $LL6@main

; 24 : }
; 25 : DWORD elapsed = GetTickCount() - start_time;

call edi
sub eax, ebx

; 26 : printf("array: %d\n", elapsed);

push eax
push OFFSET $SG-11
call _printf
add esp, 8

; 27 :
; 28 : start_time = GetTickCount();

call edi
mov ebx, eax

; 29 : for(int i = 0; i < XSIZE;i++)

xor eax, eax
$LL3@main:

; 30 : {
; 31 : vecNumbers[i]++;

inc DWORD PTR [esi+eax*4]
inc eax
cmp eax, 10000000 ; 00989680H
jb SHORT $LL3@main

; 32 : }
; 33 : elapsed = GetTickCount() - start_time;

call edi
sub eax, ebx

; 34 : printf("vector: %d\n", elapsed);

push eax
push OFFSET $SG-12
call _printf

; 35 :
; 36 : system("pause");

push OFFSET $SG-13
call _system
add esp, 12 ; 0000000cH



To simplify, I replaced ostream with printf (ostream adds lots of gunk to asm output). I also stack allocated both objects (I had to increase the stack size to accomodate the large array).

Just to highlight, for an array:

; 23 : arrayNumbers[i]++;

inc DWORD PTR _arrayNumbers$[esp+eax*4+40000056]
inc eax
cmp eax, 10000000 ; 00989680H
jb SHORT $LL6@main

; 24 : }

Whereas for a vector:

; 31 : vecNumbers[i]++;

inc DWORD PTR [esi+eax*4]
inc eax
cmp eax, 10000000 ; 00989680H
jb SHORT $LL3@main

I'm no assembly wizard, but this seems pretty comparable. On my machine I get near identical times, maybe a millisecond favouring one over the other, mine runs in ~16 milliseconds which is too close to the scheduler quantum to be a good measurement.

Upping the size by 10 and looping 10 times shows that the skew is slight in each direction, sometimes favouring vector and other times favouring the array (here both stack and a global array were used, out of curiousity):
Quote:

array: 202 <-- winner
vector: 219
static array: 405
array: 250
vector: 249
static array: 234 <-- winner
array: 219 <-- winner
vector: 296
static array: 296
array: 297
vector: 218 <-- winner
static array: 219
array: 203
vector: 187 <-- winner
static array: 219
array: 202
vector: 188 <-- winner
static array: 202
array: 219
vector: 203
static array: 202 <-- winner
array: 203
vector: 187 <-- winner
static array: 203
array: 203
vector: 202 <-- winner
static array: 203
array: 187 <-- winner (joint)
vector: 187 <-- winner (joint)
static array: 219

In the above run, there is a good mix of winners, the differences more likely due to external issues such as the cache or external processes than any intristic benefit of one technique over the other.

The source for that last test is (aside from the "winner" annotations):

#include <vector>
#include <cstdio>
#include <windows.h>

using namespace std;

const unsigned int XSIZE = 100000000;

int staticArray[XSIZE];

int main()
{
vector<int> vecNumbers(XSIZE, 0);
int arrayNumbers[XSIZE] = {};

DWORD start_time, elapsed;

for(int j = 0 ; j < 10 ; ++j) {

start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
arrayNumbers[i]++;
}
elapsed = GetTickCount() - start_time;
printf("array: %d\n", elapsed);



start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
vecNumbers[i]++;
}
elapsed = GetTickCount() - start_time;
printf("vector: %d\n", elapsed);

start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
staticArray[i]++;
}
elapsed = GetTickCount() - start_time;
printf("static array: %d\n", elapsed);
}

system("pause");
return 0;
}



Again: stack size is increased to handle the insane array.

My conclusion: bullshit

Share this post


Link to post
Share on other sites
Quote:
Original post by dpadam450
I haven't messed with boost, any other advantages to boost::array other than bounds checks?

boost::array supplies several advantages. For one thing it's a first class type unlike raw arrays, and you can do operations like assigning arrays with operator= in the intuitive manner. boost::array also provides a interface similar to that of the standard library containers. Ex:you can use begin() and end() with boost array to pass to standard library algorithms without manually doing the pointer arithmetic.

Quote:

It only does that if you use an iterator though. Maybe .at() checks bounds too?

No, pretty much every vector implementation will do bounds checks for you in debug mode using operator[]. at() is defined to do bounds checks even in release mode: it will throw an exception if you try to access an invalid element.

Share this post


Link to post
Share on other sites
Myth busted, good work guys.

Favor vectors because they don't cost anything and they are less brittle to change.

Arrays are useful in low level situations where you are dealing directly with memory allocation anyway. If you're developing a new container class, go ahead and use arrays. If you are doing basically anything more high level than that favor vectors.

Share this post


Link to post
Share on other sites
Quote:
Original post by M2tM
Favor vectors because they don't cost anything....

No, vectors typically use three machine words of storage for the vector itself and use heap allocation for the array data, which, in addition to the allocated memory, costs the bookkeeping information for the allocation, which is typically anywhere from two to six machine words, as well as potential internal or external fragmentation from using heap allocation. There's also the potential extra cache line usage in the working set because of the indirection. This adds up to a very low cost for most use cases. However, very low is not the same as zero.

Share this post


Link to post
Share on other sites
Yea well it was a myth, we all tried it so we weren't sure. But anyway try this one. Its 2D this time meaning that it can't compile down to 1 instruction anymore. See what your numbers are now.

Release I'm 100 vs 400 ms.
And again debug still counts(and this one can't be inline/optimized due to the 2D nature)
450 vs 26600 ms


#include <vector>
#include <iostream>
#include <windows.h>
using namespace std;

#define XSIZE 10000
vector<vector<int>> vecNumbers;
int arrayNumbers[XSIZE][XSIZE];
int main()
{
vecNumbers.reserve(XSIZE);
for(int i = 0; i < XSIZE; i++)
{
vecNumbers.push_back(vector<int>(XSIZE));
for(int j = 0; j < XSIZE; j++)
{
arrayNumbers[i][j] = 0;
}
}

float start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
for(int j = 0; j < XSIZE;j++)
{
arrayNumbers[i][j]++;
}
}
cout << GetTickCount() - start_time << endl;


start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
for(int j = 0; j < XSIZE;j++)
{
vecNumbers[i][j]++;
}
}
cout << GetTickCount() - start_time;

system("pause");
return 0;
}




Share this post


Link to post
Share on other sites
Quote:
Original post by dpadam450
Yea well it was a myth, we all tried it so we weren't sure. But anyway try this one. Its 2D this time meaning that it can't compile down to 1 instruction anymore. See what your numbers are now.
*** Source Snippet Removed ***


Yes, because in such a case you're comparing a situation where the array sits in a contiguous block of memory with a case where one level of indirection is required. Of course the indirection adds complexity. In such a case, you might want to use a 1d vector and calculate the index (and in most non-trivial uses of a 2d array, you'll end up having to do this anyway).

I find, in my code, that 2d arrays are very rare, so the general coding practice of using an std::vector rather than an array still holds. It is, of course, always possible to find exceptions to any rule of thumb, but that doesn't mean one should fall back on the bad practice in the general case.

Quote:
Original post by dpadam450
And again debug still counts(and this one can't be inline/optimized due to the 2D nature)
450 vs 26600 ms


It only counts if you're in the habit of doing early micro-optimizations that only benefits test builds, which is generally bad practice. If you're having practical problems with testing due to the performance hit, than sure, but its better to go back and replace the std::vector with an array if you have the performance problem and can't optimize it out rather than code with an array in the first place. That's just good programming practice (don't micro-optimize prematurely).

Share this post


Link to post
Share on other sites
Quote:

Its 2D this time meaning that it can't compile down to 1 instruction anymore. See what your numbers are now.

You are comparing apples and oranges. The "2d array" is syntatic sugar for a 1d array that is indexed differently. The "2d vector" is a completely different beast of non-contiguous arrays being stored in another array. Use the same code for both, and the time will be the same. For the "2d vector" use a 1d vector with an index function like "inline int index(int x, int y) { return x + y*width }".

Or, maybe just use boost::multi_array if that suits the application better.

Share this post


Link to post
Share on other sites
Actually I thought about the contiguous thing, but also the point to that is you can't get a 2D vector in contiguous memory. And storing it as 1D is good, but sometimes especially in spatial things like games, you want to read x,y,z for faster clarity.

I updated the code to use the dual indirection just like the vector, results:

Release: 125 vs 390
Debug: 650 vs 26600

I'm really missing what you guys are saying about Debug not mattering and that you shouldn't optimize. What I'm saying here there is nothing significant to optimize. It is a very simple function. My option for this algorithm were array or vector. Both work just fine, but if you want to run in debug some times, it kills this algorithm if you need real-time rates.

My conclusion is that yes 1D array vs vector are the same. For 100 Million elements there wasn't a significant impact. 2D or 3D though, I would never use a vector.



#include <vector>
#include <iostream>
#include <windows.h>
using namespace std;

#define XSIZE 10000
vector<vector<int>> vecNumbers;
int** arrayNumbers;
int main()
{
vecNumbers.reserve(XSIZE);
arrayNumbers = new int*[XSIZE];
for(int i = 0; i < XSIZE; i++)
{
arrayNumbers[i] = new int[XSIZE];

vecNumbers.push_back(vector<int>(XSIZE));
for(int j = 0; j < XSIZE; j++)
{
arrayNumbers[i][j] = 0;
}
}

float start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
for(int j = 0; j < XSIZE;j++)
{
arrayNumbers[i][j]++;
}
}
cout << GetTickCount() - start_time << endl;


start_time = GetTickCount();
for(int i = 0; i < XSIZE;i++)
{
for(int j = 0; j < XSIZE;j++)
{
vecNumbers[i][j]++;
}
}
cout << GetTickCount() - start_time;

system("pause");
return 0;
}



Share this post


Link to post
Share on other sites
Quote:

But anyway try this one. Its 2D this time meaning that it can't compile down to 1 instruction anymore.

I ran it five times:
Quote:

218
218
---
202
218
---
220
218
---
218
250
---
312
203

I then ran it once with a loop in it:
Quote:

328
218
---
234
203
---
219
202
---
203
234
---
219
218

The assembly output is considerably more complex for vector<> than the array this time:

Array:

mov esi, eax
lea eax, DWORD PTR _arrayNumbers$[esp+400000064]
mov edx, 10000 ; 00002710H
npad 1
$LL12@main:

; 51 : {
; 52 : for(int j = 0; j < XSIZE;j++)

mov ecx, 10000 ; 00002710H
$LL9@main:

; 53 : {
; 54 : arrayNumbers[i][j]++;

inc DWORD PTR [eax]
add eax, 4
dec ecx
jne SHORT $LL9@main

; 50 : for(int i = 0; i < XSIZE;i++)

dec edx
jne SHORT $LL12@main




Vector:

mov ecx, DWORD PTR _vecNumbers$[esp+400000064]
mov edi, eax
mov esi, 10000 ; 00002710H
npad 10
$LL6@main:

; 62 : {
; 63 : for(int j = 0; j < XSIZE;j++)

mov eax, 12 ; 0000000cH
$LL3@main:

; 64 : {
; 65 : vecNumbers[i][j]++;

mov edx, DWORD PTR [ecx]
inc DWORD PTR [eax+edx-12]
lea edx, DWORD PTR [eax+edx-12]
mov edx, DWORD PTR [ecx]
inc DWORD PTR [eax+edx-8]
lea edx, DWORD PTR [eax+edx-8]
mov edx, DWORD PTR [ecx]
inc DWORD PTR [eax+edx-4]
lea edx, DWORD PTR [eax+edx-4]
mov edx, DWORD PTR [ecx]
inc DWORD PTR [edx+eax]
mov edx, DWORD PTR [ecx]
inc DWORD PTR [eax+edx+4]
lea edx, DWORD PTR [eax+edx+4]
add eax, 20 ; 00000014H
cmp eax, 40012 ; 00009c4cH
jl SHORT $LL3@main

; 61 : for(int i = 0; i < XSIZE;i++)

add ecx, 16 ; 00000010H
dec esi
jne SHORT $LL6@main


The compiler appears to have partially unrolled the loop for the vector.

In vanilla Debug mode std::vector is indeed (and obviously) orders of magnitude slower.

In any case, a more direct comparison might be with boost::multi_array. I have a 2 dimensional vector class that uses a contiguous std::vector<> for storage.

Share this post


Link to post
Share on other sites
Quote:
Original post by dpadam450
Actually I thought about the contiguous thing, but also the point to that is you can't get a 2D vector in contiguous memory. And storing it as 1D is good, but sometimes especially in spatial things like games, you want to read x,y,z for faster clarity.


"Spatial things"? Well, if you're planning on passing that array around and at least one of the dimensions isn't known at compile time, you're going to be handling that 2D array as a 1D array anyway. I suppose if you can handle it across the board as a 2D array then you might have a point, but in practice I've found this to be fairly rare.

Quote:
Original post by dpadam450
I'm really missing what you guys are saying about Debug not mattering and that you shouldn't optimize.


Apparently. We're not saying "Don't optimize." We're saying "Don't micro-optimize prematurely." Picking an array based on the idea that "Its faster in debug mode!" is worrying about the wrong things. You can always change that std::vector into an array in the rare case that its a problem. But what are the chances that it will actually be an issue, and that its an issue that can't be fixed by tweaking compiler settings? Not likely, so use the correct way for now, and change it if your frame rate is too low in debug. Program for the general case, not the special case.

Quote:
Original post by dpadam450
What I'm saying here there is nothing significant to optimize. It is a very simple function. My option for this algorithm were array or vector. Both work just fine, but if you want to run in debug some times, it kills this algorithm if you need real-time rates.


No, you made a generalized statement about how you should use arrays instead of vectors if you didn't need resizing because they were faster, and we called you out on it. You've made a preemptive judgement that extensive usage of vector will kill you if you need "real-time rates" in debug mode.

Quote:
Original post by dpadam450
My conclusion is that yes 1D array vs vector are the same, for 100 Million elements there wasnt a significant impact. 2D or 3D though, I would never use a vector.


Never? Again, your tests are pretty arbitrary. Yes, if you don't want to treat your vector as contiguous memory and calculate indexes, you'll get a performance hit. The problem is that complex use of 2D arrays will also require the same index-calculating shenanigans. If that's the case, you might as well just use a vector.


And I'd like to note you started out this thread under the pretense of giving helpful advice, then gave potential newbies bad advice. Stop doing that, please.

Share this post


Link to post
Share on other sites
Quote:

I'm really missing what you guys are saying about Debug not mattering and that you shouldn't optimize.

First off, because no-one but the developer is going to see the debug mode, you should worry about the release mode first. Also, the optimizations that happen in release are specific to your code, and can remove "bottlenecks" that aren't really there. Prematurely optimizing can actually make the compiler's job harder, resulting in poorer release code.

Secondly, don't optimize till it becomes a problem. Just because your esoteric "benchmark" code shows that arrays are faster doesn't mean anything. The array access itself may be trivial compared to some other bottleneck in the code. The difference in time between an array and a vector is perfectly trivial compared to the time spent in a memory stall from a cache miss.

Thirdly, std::vector is tested, and has lots of error checking and no manual memory management for you to screw up. Both simple things to forget when making your own arrays with new/delete.

Lastly, you also have to consider that a std::vector is a "general case" structure. It provides you with fast insertions, work with any type, has generic algorithms, etc. Your array is very specific, resulting in lots of duplicated code, magic numbers (where is std::vector::size() for your array??), and inflexibility to expantion/contraction.

ps. I'm really amazed how many times this myth comes up. I know not all programmers have had the chance to go through college yet (and thus take a compilers course and learn about optimizations), but still...

Share this post


Link to post
Share on other sites
Ultimately, my experience with this kind of question is that unless you're willing to throw down an example of a compiler doing its good work people simply won't accept that vector<> can be as fast as a raw array.

In any case, you rarely know the size. Most of the times, the "size" is some heuristic guesstimate that you hope won't need to change soon, not a absolute domain constant (there are few such things). The easiest way is to write your code for the more general case. If speed is a problem, as the others have said, optimise it *then*.

The advantage of having debug bounds checking cannot be overstated. Correctness before speed. I don't like to measure performance in how fast a program crashes.

@dpadam450 Your code speaks of one who is uncertain that the compiler will do obvious optimisations. Use of the preprocessor rather than const integers hints at this. If this is really the case, then you should really think hard about whether you should be telling people what is "fast", even when your experience dictates otherwise.

Had you presented your original post as a question rather than as fact, we would have gone easier on you. The fact remains though that it is because of people like yourself who propagate outdated assumptions that this myth persists and another generation refuses to use the tools that come with the language for some vague promises of performance which they never hit.

Share this post


Link to post
Share on other sites
Quote:

Picking an array based on the idea that "Its faster in debug mode!"


That is a valid point but I run in debug a lot. But regardless, it still has run faster in release for me every single time as well.

Quote:

Had you presented your original post as a question rather than as fact, we would have gone easier on you.


Fair enough. I added 'tip' in the edit after I had run it. You must have something check marked to get it to optimize vectors better than mine cuz I'm always about 3 times slower.

Quote:

First off, because no-one but the developer is going to see the debug mode. Secondly, don't optimize till it becomes a problem.


Well 26 seconds vs 1/2 second is a problem. So in a respectful way, I as the developer have a problem (26 seconds), that I as the developer see because I see debug mode :(

And I had seen some code with a 3D vector which now I know why it is very slow because it stores like 1 million things. Also the code never called the reserve function :( So, yes it does happen that people still don't reserve vectors.

Share this post


Link to post
Share on other sites
Quote:
Original post by dpadam450
Well 26 seconds vs 1/2 second is a problem. So in a respectful way, I as the developer have a problem (26 seconds), that I as the developer see because I see debug mode :(


If its a game, you have a problem whether its 26 seconds or 1/2 second. That would imply a very bad algorithm that should be the focus of your efforts rather than swapping out std::vector for an array, or possibly using std::vector in a sane manner, since your benchmark doesn't do so.

Again, you're 1) optimizing for a special case (debug mode) not the general case (release mode), 2) focusing on the wrong thing (trying to out-think the compiler rather than using data structures intelligently), 3) using an artificial benchmark to prematurely make performance decisions. If your game is spending 1/2 of a second in vector/array code, then there are larger problems afoot.

Share this post


Link to post
Share on other sites
The single thing you can rightfully blame std::vector of is the fact that every vector must do at least one heap allocation and if you have more than a dozen or so elements, it must at least do two heap allocations (and will do log(N) allocations if you keep pushing_back without reserving).
On the other hand, declaring int array[10000000]; like in your example takes about 40 MB of stack space, which honestly is a number that very well justifies a heap allocation. In fact, I'm surprised your program doesn't crash, because with default options, you only have a 1 MB stack size, if I remember correctly.

Other than for the allocations, it isn't worth to worry about overhead. While I can't say much about MSVC (since I'm not using it), chances are that it is not optimizing much worse than gcc (this can be safely assumed).
And gcc on the other hand, optimizes most of STL and TR1 into the exact same (and sometimes better) code as carefully hand-tuned specialized code. It is a total waste of time to try and do any better.

Share this post


Link to post
Share on other sites
Moving to General Programming so we can stop distracting beginners with potentially dangerous and/or wrong ideas, and take off the kid gloves and tell people when they're wrong.

Share this post


Link to post
Share on other sites
Quote:
Original post by dpadam450
That is a valid point but I run in debug a lot. But regardless, it still has run faster in release for me every single time as well.

I'm using Visual Studio 2010 Express Edition. I've used a reasonably vanilla Release mode build with the exception of the following preprocessor definitions at project scope:

  • _HAS_ITERATOR_DEBUGGING=0

  • _SECURE_SCL=0


Some non-performance settings are changed (e.g. generating assembly output), as I use this project for all GD.net related code.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement