How are you running your app? If from within the IDE make sure you use CTRL-F5 (start without debugging) as opposed to just F5 (Debug).

Thanks mate it worked. Where is defined the CTRL+F5 shortcut?
Thanks a lot.

EDIT: if i build and run my project from outside the ide its equal to launching with CTRL+F5 from inside VS?

The code is for the 99.9% the same.[/quote]The code you see is 99% the same. In reality, your entire codebase represents the 0.01%. The first large invisible part is standard library aka the STL, which is compiler specific and implemented independently. Then there is compiler itself. Final unknown is the operating system. Depending on what gets linked and how, resulting executable could be using different parts of OS. One reason for this might be that MSVC will be up to date with latest "secure" versions while gcc-based ones would use older versions.

But as far as low hanging fruit goes:

The heuristics of std::vector implementation (and other containers) differ between MSVC and gcc. One of likely causes would be not sizing them at the beginning. Additional resizing could add to performance issues. This may require some code change, but tends to be biggest algorithmic gain. Preallocating can result in up to factor of 10 improvement in some cases.

Another factor would be how operator new/malloc are implemented. MSVC's was improved over time, but it does not strictly prioritize running time. If there are many allocations, this would be lead to overall increase in running times. If you use new frequently for small objects (<16 bytes), then gcc is likely to behave better. MSVC and underlying WinAPI syscalls do not prioritize small allocations by default. It depends on choice of containers.

std::string and vector in MSVC are coded (IIRC) slightly more defensively, so they tend to have bulkier operations. While they were algorithmically better, there are many cases where they could take longer than GCC equivalent. I don't know if this is still true.

The code is for the 99.9% the same.

The code you see is 99% the same. In reality, your entire codebase represents the 0.01%. The first large invisible part is standard library aka the STL, which is compiler specific and implemented independently. Then there is compiler itself. Final unknown is the operating system. Depending on what gets linked and how, resulting executable could be using different parts of OS. One reason for this might be that MSVC will be up to date with latest "secure" versions while gcc-based ones would use older versions.

But as far as low hanging fruit goes:

The heuristics of std::vector implementation (and other containers) differ between MSVC and gcc. One of likely causes would be not sizing them at the beginning. Additional resizing could add to performance issues. This may require some code change, but tends to be biggest algorithmic gain. Preallocating can result in up to factor of 10 improvement in some cases.

Another factor would be how operator new/malloc are implemented. MSVC's was improved over time, but it does not strictly prioritize running time. If there are many allocations, this would be lead to overall increase in running times. If you use new frequently for small objects (<16 bytes), then gcc is likely to behave better. MSVC and underlying WinAPI syscalls do not prioritize small allocations by default. It depends on choice of containers.

std::string and vector in MSVC are coded (IIRC) slightly more defensively, so they tend to have bulkier operations. While they were algorithmically better, there are many cases where they could take longer than GCC equivalent. I don't know if this is still true.
[/quote]

Thanks for your time it's a good reading.