Other answers are very good, but you could easily answer it yourself by this method.
ADDED: In response to comments, let me show you what I mean. I'm running VC On Windows, but this works on any language/OS. I took your first program and increased size to 20000 so it would run long enough. Then while it was running, I took several stackshots. They all look like this:
std::vector<bool,std::allocator<bool> >::begin() line 93 + 25 bytes
std::vector<bool,std::allocator<bool> >::operator[]() line 132 + 37 bytes
main() line 24 + 12 bytes
mainCRTStartup() line 206 + 25 bytes
KERNEL32! 7c817077()
So what that says is that it is spending essentially all of it's time in the indexing operation on line 24, and the reason it's spending that time is that the []
operator is calling the begin
operator. In more detail:
main() line 24 + 12 bytes
is this code:
for(int j = 0; j < size; j++){
==> v[i] = true;
}
that calls:
std::vector<bool,std::allocator<bool> >::operator[]() line 132 + 37 bytes
which is this code (that I reformatted a little bit):
reference operator[](size_type _P){
==> return (*(begin() + _P));
}
that calls:
std::vector<bool,std::allocator<bool> >::begin() line 93 + 25 bytes
which is doing this (in more detail):
92: iterator begin()
93: {return (_First); }
00402890 push ebp
00402891 mov ebp,esp
00402893 sub esp,44h
00402896 push ebx
00402897 push esi
00402898 push edi
00402899 push ecx
0040289A lea edi,[ebp-44h]
0040289D mov ecx,11h
004028A2 mov eax,0CCCCCCCCh
004028A7 rep stos dword ptr [edi]
004028A9 pop ecx <===============
004028AA mov dword ptr [ebp-4],ecx
004028AD mov eax,dword ptr [ebp-4]
004028B0 mov eax,dword ptr [eax+4]
004028B3 pop edi
004028B4 pop esi
004028B5 pop ebx
004028B6 mov esp,ebp
004028B8 pop ebp
004028B9 ret
What it is doing is writing 68 bytes of 0xCC
on the stack (for some debug reason) as part of getting the begin
address of the vector, as part of computing the address of v[i]
, prior to doing the assignment.
The fraction of time it spends doing this is near 100%, because it was doing it on every one of the several samples that were taken. Could you have guessed that that's what it was spending nearly all of its time doing? I couldn't have.
This is, of course, a Debug build. If you switch to a Release build, but turn on debugging information, all these functions get inlined and optimized away, so it goes like 30 times faster, and again the stackshots tell exactly what it's doing.
So - people can tell you what it might be doing, but this shows how to find out for yourself what it is really doing.
On your environment it will undoubtedly be different.