Code runs slower in Release mode than in Debug mode

koliva · wrote on 10 Jan 2013, 12:37

Hello all,

This is my first question related to my code.
I have an application in which I encode a video by using x264 encoder. I basically use the libraries and dlls of x264 and call its functions when necessary. When I run it in Debug mode, it works really perfect and fast. However, when I build and run it in Release mode, it slows down. First thing that came into my mind was the compiler options for release mode but I don't know them in detail. Therefore, I would like you to help me to find the reason causing the delay in my code.

Thank you very much in advance.

koahnig · wrote on 10 Jan 2013, 12:50

welcome to devnet

What you are reporting sounds very strange. Typically it is the other way around. Debug mode applications do run slower because of extra checks and if you run in a debugger, it is typically even slower.

Whatever the problem is, you have to give more details to OS, compiler and stuff you are using.

koliva · wrote on 10 Jan 2013, 12:55

[quote author="koahnig" date="1357822258"]welcome to devnet

What you are reporting sounds very strange. Typically it is the other way around. Debug mode applications do run slower because of extra checks and if you run in a debugger, it is typically even slower.

Whatever the problem is, you have to give more details to OS, compiler and stuff you are using. [/quote]

The problem is very strange to me as well. I am running Qt Creator 2.6.0 based on Qt 4.8.3 (32 bit). My OS is Win7 and it's a Dell Latitude E6430 laptop.

I suspect the dlls but I have no idea where to look for their correctness. I build them using MinGW.

MuldeR · wrote on 10 Jan 2013, 13:09

[quote author="koliva" date="1357821474"]Hello all,

This is my first question related to my code.
I have an application in which I encode a video by using x264 encoder. I basically use the libraries and dlls of x264 and call its functions when necessary. When I run it in Debug mode, it works really perfect and fast. However, when I build and run it in Release mode, it slows down. First thing that came into my mind was the compiler options for release mode but I don't know them in detail. Therefore, I would like you to help me to find the reason causing the delay in my code.

Thank you very much in advance.[/quote]

I have to ask the obvious: Do you have any "#ifdef"' constructs in your code that enable/disable code based on whether it is compiled as Release or Debug and thus would explain the issue?

Other than that, I would recommend to do a performance analysis of your release code and figure out where the "bottleneck" is. On Linux you could use "gprof" for that. On Windows I'm not aware of a free solution that gives reasonable results. I made good experience with "Bounds Checker" though. Also the built-in profiling tools of Visual Studio 2012 (I think only available in the "Ultimate" edition) worked okay for me too. Finally there is "AMD CodeAnalyst" which is free and works on Intel systems too, but is not very detailed...

Last question: When you compiled the "Release" binaries, did you use an-up-to-date MinGW and did you have all the compiler optimizations enabled? Also: Did you compare with Visual Studio compiled "Release" version? (You can use "free" edition).

koahnig · wrote on 10 Jan 2013, 13:12

Which dlls do you blame?

koliva · wrote on 10 Jan 2013, 14:03

[quote author="MuldeR" date="1357823373"]

I have to ask the obvious: Do you have any "#ifdef"' constructs in your code that enable/disable code based on whether it is compiled as Release or Debug and thus would explain the issue?[/quote]

I do have lots of "#ifdef" constructions but they are never based on release or debug.

[quote author="MuldeR" date="1357823373"]
Other than that, I would recommend to do a performance analysis of your release code and figure out where the "bottleneck" is. On Linux you could use "gprof" for that. On Windows I'm not aware of a free solution that gives reasonable results. I made good experience with "Bounds Checker" though. Also the built-in profiling tools of Visual Studio 2012 (I think only available in the "Ultimate" edition) worked okay for me too. Finally there is "AMD CodeAnalyst" which is free and works on Intel systems too, but is not very detailed...

Last question: When you compiled the "Release" binaries, did you use an-up-to-date MinGW and did you have all the compiler optimizations enabled? Also: Did you compare with Visual Studio compiled "Release" version? (You can use "free" edition).[/quote]

I used mingw-get-inst-20120426 and I have just checked that it is the latest one.
However, I remember that the mingw was looking for yasm.exe and I found it from somewhere and put it under bin folder myself. I checked the version of the yasm and it is yasm 1.2.0, compiled on Oct 31 2011. When I was building the dlls, I used the instructions from http://www.ayobamiadewole.com/Blog/Others/x264compilation.aspx. Do you see any problems there in the configuration?

[quote author="koahnig" date="1357823520"]Which dlls do you blame?

[/quote]

Mainly libx264.dll

MuldeR · wrote on 10 Jan 2013, 14:09

Well, if it turns out it's not actually the GUI-related stuff, but the encoder DLL, that is slow, your problem isn't Qt related. You then should try to track down the problem with your "libx264.dll" file then.

x264 will be really slow, if you build it without Assembly enabled. To build with Assembly, YASM is require. But the configure script of x264 won't let you build without Assembly anyway - unless you add "--disable-asm".

If you can live with an x264 that is outdated by a few months, you could compare to the last DLL's I compiled:
"libx264-125-r2200M-win32.7z":http://code.google.com/p/mulder/downloads/detail?name=libx264-125-r2200M-win32.7z&can=2&q=&sort=filename+-uploaded

(Will have to make some "fresh" builds soon ^^)

koliva · wrote on 10 Jan 2013, 14:13

[quote author="MuldeR" date="1357826995"]Well, if it turns out it's not actually the GUI-related stuff, but the encoder DLL, that is slow, your problem isn't Qt related. You then should try to track down the problem with your "libx264.dll" file then.

x264 will be really slow, if you build it without Assembly enabled, which requires YASM. But the configure script of x264 won't let you build without Assembly - unless you add "--disable-asm".[/quote]

I will try to compile the dll based on the instructions given in http://doom10.org/index.php?topic=26.0. I will report back the results.

koliva · wrote on 11 Jan 2013, 09:37

[quote author="MuldeR" date="1357826995"]Well, if it turns out it's not actually the GUI-related stuff, but the encoder DLL, that is slow, your problem isn't Qt related. You then should try to track down the problem with your "libx264.dll" file then.

x264 will be really slow, if you build it without Assembly enabled. To build with Assembly, YASM is require. But the configure script of x264 won't let you build without Assembly anyway - unless you add "--disable-asm".

If you can live with an x264 that is outdated by a few months, you could compare to the last DLL's I compiled:
"libx264-125-r2200M-win32.7z":http://code.google.com/p/mulder/downloads/detail?name=libx264-125-r2200M-win32.7z&can=2&q=&sort=filename+-uploaded

(Will have to make some "fresh" builds soon ^^)[/quote]

Hi Mulder,

I have been trying to compile the dll with MinGW based on the instructions in http://www.ayobamiadewole.com/Blog/Others/x264compilation.aspx. For some reason, I couldn't compile it. The MinGW gives error like "No working C compiler found.". Although I did a search on it, I couldn't resolve it. Then I tried to use your builds. However, I statically link the dll and for this, I use libx264.lib as well. I don't see this lib in your builds. Could you please guide me where to find the libx264.lib or why I am getting the error that I wrote above in MinGW?
Thanks.

MuldeR · wrote on 11 Jan 2013, 14:15

About your error: Well, it didn't find a C compiler ;-)

If you type "gcc -v" in the same console (MSYS) where you are going to run "./configure", what happens?

For details, see the "config.log" file that was created...

--

About the .lib file: What you are used to from MSVC as a .lib file will be an .a file with GCC/MinGW.

Indeed, I did not package the .a file (import library) along with the DLL's, because those were intended as a drop-in replacement for Avidemux (or similar tools that already use an existing libx264.dll).

But: It seems you already compiled x264 yourself, only your builds were "too slow". So if you build x264 again the way you did before, you should get the .a file plus a DLL. You can then simply replace that DLL with my DLL for comparison. Note, however, you will have to compile the .a file that matches my DLL's, so will have to compile x264 r2200 (core-125), aka GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

Also, when you compile the application that uses the x264 DLL, you have to use the .h file from r2200 then!

koliva · wrote on 11 Jan 2013, 14:38

[quote author="MuldeR" date="1357913737"]About your error: Well, it didn't find a C compiler ;-)

If you type "gcc -v" in the same console (MSYS) where you are going to run "./configure", what happens?

For details, see the "config.log" file that was created...

--

About the .lib file: What you are used to from MSVC as a .lib file will be an .a file with GCC/MinGW.

Indeed, I did not package the .a file (import library) along with the DLL's, because those were intended as a drop-in replacement for Avidemux (or similar tools that already use an existing libx264.dll).

But: It seems you already compiled x264 yourself, only your builds were "too slow". So if you build x264 again the way you did before, you should get the .a file plus a DLL. You can then simply replace that DLL with my DLL for comparison. Note, however, you will need to compile .a file that matches my DLL's, so will have to compile x264 r2200 (core-125), aka GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

Also, when you compile the application that uses the x264 DLL, you have to use the .h file from r2200 then![/quote]

Hi Mulder,

I have just found the problem about compilation error. This is how I made the dll and lib:

I typed in MinGW,

./configure
make (exe is created.)
./configure --disable-cli --enable-shared --extra-ldflags=-Wl,--output-def=libx264.def
make (dll is created)
In MSVC command prompt I typed,
LIB /DEF:libx264.def (lkib is created)

The error that I got was just because I was mistyping --extra-ldflags. I mean instead of Wl I was typing wl :)

With the new dll and lib, I still have the same problem. In release mode it runs slower. Actually "slower" word may not be correct. I am having 500 ms latency in Release mode and about 90 ms in Debug mode.

My question now is that, what happens if I run the 5. step above for your dll? Won't it create lib file for your dll?

MuldeR · wrote on 11 Jan 2013, 14:46

Yes, but you would need the correct "libx264.def" for x264 r2200 (core-125)!

--

Also: What do you mean with "delay"? It's normal that the call to x264_encoder_encode() will block some time.

The first few calls will return right away, returning nothing. That's because x264 internally buffers frames.

But once the buffer has been filled, each call will return an encoded frame and thus not return until the next frame has been encoded. You rally have to think of "speed" as the frames per second averaged for the whole clip.

koliva · wrote on 11 Jan 2013, 14:52

[quote author="MuldeR" date="1357915574"]Yes, but you would need the correct "libx264.def" for x264 r2200 (core-125)!

Also: What do you mean with "delay"? It's normal that the call to x264_encoder_encode() will block.

The first few calls will return right away, returning nothing. That's because x264 internally buffers frames.

But once the buffer has been filled, each call will return an encoded frame and thus not return until the next frame has been encoded. You rally have to think of "speed" as the frames per second averaged for the whole clip.[/quote]

I meant latency by delay. Let me explain my application to you.
I am capturing the screen and encoding it with x264 and sending it to another computer over network and there it is decoded and visualized. So I have basically two laptops and I open a timer with millisecond accuracy. then I put the two screens next to each other and take a picture. I calculate the latency by subtracting the two values.
The problem is, when I run my code in Release mode, I see about 500 ms latency while if I run exactly the same code in Debug mode, I got 90 ms latency. I am breaking my calls to find what causing this.

MuldeR · wrote on 11 Jan 2013, 14:58

Are you even using the same x264 settings ?????

x264 does have some delay, because of lookahead and stuff. Good for "offline" encoding, but can be a problem for "real time" streaming. Latency can be much reduced by tweaking encoder settings! The CLI encoder has a special option "--tune zerolatency" for this purpose. Also "--preset" controls overall encoder speed.

(Maybe the "Debug" build just happens to use other settings that happen to reduce latency)

koliva · wrote on 11 Jan 2013, 15:05

[quote author="MuldeR" date="1357916334"]Are you even using the same x264 settings ?????

x264 does have some delay, because of lookahead and stuff. Good for "offline" encoding, but can be a problem for "real time" streaming. Latency can be much reduced by tweaking encoder settings! The CLI encoder has a special option "--tune zerolatency" for this purpose. Also "--preset" controls overall encoder speed.

(Maybe the "Debug" build just happens to use other settings that happen to reduce latency)[/quote]

The code is exactly the same. Actually it's a quite a short code since I use the default presets with VBV encoding.

For the encoder settings I use:

x264_param_default( &param );
x264_param_default_preset(&param, "ultrafast", "zerolatency");    
param.i_width = aWidth;
param.i_height = aHeight;

param.i_keyint_max = X264_KEYINT_MAX_INFINITE;
param.i_keyint_min = X264_KEYINT_MAX_INFINITE;
param.rc.i_vbv_max_bitrate = 5600;     //Bitrate in kbps
param.rc.i_vbv_buffer_size = param.rc.i_vbv_max_bitrate/40;

I really want to try your dll in my system. I have checked my dll build and its version is
#define X264_BUILD 129
in x264.h. Could you please tell me step by step how to compile yours? Is it just replacing the libx264.dll.a with your dll and changing the extension again to .dll.a ?

MuldeR · wrote on 11 Jan 2013, 15:11

Nope.

Check out x264 r2200 (core-125).

As said before, that's GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

That revision has the suitable .h file. Also, if you compile that, as usual, it will give you the needed .a file.

BTW: The .dll.a file is the equivalent to the .lib file from MSVC's LIB tool. It's not the DLL!

--

Did you verify x264_param_default() and x264_param_default_preset() do the same in Debug/Release ???

koliva · wrote on 11 Jan 2013, 15:28

[quote author="MuldeR" date="1357917061"]Nope.
As said before, that's GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

That revision has the suitable .h file. Also, if you compile that, as usual, it will give you the needed .a file.

BTW: The .dll.a file is the equivalent to the .lib file from MSVC's LIB tool. It's not the DLL!

--

Did you verify x264_param_default() and x264_param_default_preset() do the same in Debug/Release ???[/quote]

In Git GUI I connected to the server which is git://git.videolan.org/ and I can clone the last version. But I don't know how I can check out x264 rr2200. Could you please help me?

How can I verify what they are doing in Debug and Release mode?

MuldeR · wrote on 11 Jan 2013, 15:37

[quote]In Git GUI I connected to the server which is git://git.videolan.org/ and I can clone the last version. But I don't know how I can check out x264 rr2200. Could you please help me?[/quote]

If on Windows, do yourself a favor and use TortoiseGIT! Or just use the GIT console:
http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html

[quote]How can I verify what they are doing in Debug and Release mode?[/quote]

Check the content of your x264_param_t after the call and compare...

MuldeR · wrote on 11 Jan 2013, 20:48

Just checked my HDD at home and found the old x264 build files :-)

So here is libx264.DLL r2200 (core-125) including the correct header files and import library:
http://www.mediafire.com/file/637yqnuiqu3nuua/libx264_r2200_gcc471_x86.zip

Note: libx264.dll.a is the import library (to link against the DLL) while libx264.a is the static library.

koliva · wrote on 12 Jan 2013, 19:15

[quote author="MuldeR" date="1357937312"]Just checked my HDD at home and found the old x264 build files :-)

So here is libx264.DLL r2200 (core-125) including the correct header files and import library:
http://www.mediafire.com/file/637yqnuiqu3nuua/libx264_r2200_gcc471_x86.zip

Note: libx264.dll.a is the import library (to link against the DLL) while libx264.a is the static library.[/quote]

Hi Mulder,

Thanks a lot for your help. I am currently not available to try it out but Monday I will certainly give it a try. Thanks a billion.