21 replies to this topic

[broady]

Hello gd people,
i had my c++/opengl project running fine on CodeBlocks (with MINGW compiler). The debugger but was not so handly so i decided to move all the code in VS2010 Express edition.

The code is for the 99.9% the same. The 0.1% difference comes from stuff that compiles on CB and not in VS and i had to change.

My program is a win32 project. In the strarting it has to do lot of calcs because it has to build a mesh representing an image. The mesh is a complex object containing members like stl Vectors of pointers to vertices, edges, faces etc...

Why the hell when i run the program in VS it takes much longer respect to CB? Of course i run everything in release. Once the mesh is builded i cant notice any different in performance.
But at the start, before the first image appears in the drawning window, we speak of 1-2 seconds in CB versus 10-15 seconds in VS.
Might be express edition the problem?

Thanks fellows!
Riziero

[Hodgman]

By default, MSVC generates debug-safety code for STL containers (even in release builds), which makes iterating over them (and other operations) excessively slow.

In your projects properties, you want to add the definitions:
_SCL_SECURE_NO_WARNINGS
_SECURE_SCL=0

[BitMaster]

Are you running a debug or release build when you measure those times?

Nevermind.

[AndyEsser]

Are you running a debug or release build when you measure those times?

He did say he's running in Release when measuring the times.

I would go with Hodgmans suggestion.

[broady]

Are you running a debug or release build when you measure those times?

He did say he's running in Release when measuring the times.

I would go with Hodgmans suggestion.

Thanks for fast reply.
I will try when i am back to homeand let you khnow

[zacaj]

Thats pretty wierd. Without even adding that setting, my speed in VC2010 is about 3x codeblocks when both are in the default release modes

[SiCrane]

By default, MSVC generates debug-safety code for STL containers (even in release builds), which makes iterating over them (and other operations) excessively slow.

In your projects properties, you want to add the definitions:
_SCL_SECURE_NO_WARNINGS
_SECURE_SCL=0

Actually, that only applies to MSVC 2005 and 2008. In MSVC 2010 _SECURE_SCL is disabled by default in release builds. Also, _SCL_SECURE_NO_WARNINGS has no performance impact.

[fastcall22]

Try running your program through a profiler (such as AMD's CodeAnalyst) to get a better look under the hood.

[_Unicron_]

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).

[Andrew Kabakwu]

By default, MSVC generates debug-safety code for STL containers (even in release builds), which makes iterating over them (and other operations) excessively slow.

In your projects properties, you want to add the definitions:
_SCL_SECURE_NO_WARNINGS
_SECURE_SCL=0

How do you do this? Under which section?

[SiCrane]

You would set those in the preprocessor definitions.

[broady]

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?

[zacaj]

Yes. CTRL+F5 (which I bind to F6 for ease of use) is run without debugging (basically just running the exe)

[_Unicron_]

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

You can see if in the Debug drop-down menu. Or do you mean where is the keyboard mapping defined? If so :

Tools->Customize, Click the keyboard button. Scroll down to Debug.StartWithoutDebugging in the next window and you can see the keyboard shortcut and change it if you wish.

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

Yes

[broady]

yes i was expecting to see ctrl+F5 in the debug menu. Its not there, at least by default.

[taz0010]

Is your startup code very heavy on memory allocation? Some parts of my program incur almost twice as much overhead within the IDE in release mode due to the debug allocators (which are only used when running inside the IDE, so don't worry).

Also are you compiling with SSE extensions and the floating point model set to fast? The default settings (no SSE, fp:precise) are extremely slow (factor of 4-5x) when doing heavy work with floating point values.

[Cambo_frog]

yes i was expecting to see ctrl+F5 in the debug menu. Its not there, at least by default.

It should be. The menu item is titled " Start Without Debugging Ctrl + F5".

I have pro version of VS2010, but I can't see it being any different in the express version.

[Antheus]

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.

[broady]

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.

Thanks for your time it's a good reading.

[Aressera]

I'm having a similar issue with the sound propagation simulation library I'm developing: Compiling with GCC under Xcode I'm getting around 50fps, while when compiling using MSVC it runs at around 37fps. I'm dual-booting the same computer and compiling with all optimizations turned on in release mode for both platforms. I tried the 'run without debugging' option and didn't notice any improvement. My project doesn't make any use of STL so I can't blame different implementations. I'll also note that I'm heavily using the __forceinline directives for each compiler, so I don't think that it could be differences in inlining strategies.

Could it be that GCC's optimizer is better than MSVC's? Does anyone have any ideas for how I could improve the performance of my system when compiling using MSVC? I suppose I could always use GCC to compile under windows if I had to...