Debug and Release Mode.
BLR, EXTN. 3323 APPLICATIONS
Monday, January 22, 1996
Hi all,
I have a problem with my VC++ 1.52 application. I had used the Debug option
for my project for development and tested the application. The application
works fine. If I use the Project Release Mode, the application suddenly
becomes too slow.
Let me explain.
My application is an MDI application, with a derived CFormView Class as the
View. I have a VBX Grid Control in the View. When I run the program in the
Debug Mode, the application works just fine. When I switch to the Release
Mode, The applications executes. But, when I click on the New ToolBar
option or select the New option from the File Menu, the View window takes
a very long time to appear. I am unable to see any problem. I tried to keep
the Warning Level to 4 and Build the Application. I did not find any error
except the Conversion from Int to Unsigned int problem.
I am working on Win 95. I am developing a 16-bit application using VC++
1.52/MFC 2.52.
Can any of u help me out in this?
Thanx in Advance.
Narayan.
.\\\.
( 0 0 )
____________________________.oOo__( ^ )__oOo.____________________________
(_) \~/ (_)
| | Narayanan M C email : NARAYAN_M1@blrv1.verifone.com | |
| | Development Engineer, R&D, | |
| | Verifone India Pvt. Ltd., | |
| | Bangalore - 560 001, India. | |
| | Ph: 91-80-2269920, 2269924 Extn. 3323 | |
| | 91-80-5541523, 5541524 Extn. 3323 | |
| | | |
| | Res: 91-80-3440275 | |
| | | |
| | In VuFone Screen Format Generator (VC++ 1.52/MFC 2.52/Win 95) !!! | |
| |____________________________.oooO___Oooo.____________________________| |
(_) ( ) ( ) (_)
\ ( ) /
\_) (_/
Niels Ull Jacobsen -- nuj@kruger.dk
Wednesday, January 24, 1996
[Mini-digest: 3 responses]
> I have a problem with my VC++ 1.52 application. I had used the Debug option
> for my project for development and tested the application. The application
> works fine. If I use the Project Release Mode, the application suddenly
> becomes too slow.
I don't have any direct explanation of the problems you're
experiencing, but in general, problems when switching to release mode
can usually be attributed to one of the following:
1. Uninitialised variables. In MSVC 1.5x, the debug mode compiler will
zero all variables when they're created. In release mode, it won't.
This is *the* most common problem. Check *all* constructors to see
that *all* members are properly initialised. I don't think this
applies for MSVC 2.0 or later.
2. Using ASSERT where you meant VERIFY. This can easily be checked by
adding #define ASSERT VERIFY to your stdafx.h and testing your
program. If it suddenly works, you know what to look for. This simple
approach won't work if you have specific debug-only variables, which
you ASSERT upon.
3. Compiler optimisation errors. These are not so frequent, but they
occur. Turn off all optimisations to see if this is your problem.
BTW, You can generate debug information in release mode versions -
then you can step through the code and perhaps see what goes wrong.
If you have performance problems, it might be a good idea to use a
profiler to find out what is taking such a long time. Or simply add
debug info, start your program in the debugger and press break while
it is doing whatever takes so long time. If you're lucky, the call
stack will tell you what it is doing. The system debug symbols can be
nice to have in this case, as they will give you a better idea of what
is happening.
> Let me explain.
>
> My application is an MDI application, with a derived CFormView Class as the
> View. I have a VBX Grid Control in the View. When I run the program in the
> Debug Mode, the application works just fine. When I switch to the Release
> Mode, The applications executes. But, when I click on the New ToolBar
> option or select the New option from the File Menu, the View window takes
> a very long time to appear. I am unable to see any problem. I tried to keep
> the Warning Level to 4 and Build the Application. I did not find any error
> except the Conversion from Int to Unsigned int problem.
>
> I am working on Win 95. I am developing a 16-bit application using VC++
> 1.52/MFC 2.52.
>
> Can any of u help me out in this?
>
> Thanx in Advance.
> Narayan.
> .\\\.
> ( 0 0 )
> ____________________________.oOo__( ^ )__oOo.____________________________
> (_) \~/ (_)
> | | Narayanan M C email : NARAYAN_M1@blrv1.verifone.com | |
> | | Development Engineer, R&D, | |
> | | Verifone India Pvt. Ltd., | |
> | | Bangalore - 560 001, India. | |
> | | Ph: 91-80-2269920, 2269924 Extn. 3323 | |
> | | 91-80-5541523, 5541524 Extn. 3323 | |
> | | | |
> | | Res: 91-80-3440275 | |
> | | | |
> | | In VuFone Screen Format Generator (VC++ 1.52/MFC 2.52/Win 95) !!! | |
> | |____________________________.oooO___Oooo.____________________________| |
> (_) ( ) ( ) (_)
> \ ( ) /
> \_) (_/
>
>
>
--
Niels Ull Jacobsen, Kruger A/S
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger
group and should be taken as legally binding in every respect. Pigs
will grow wings and fly.
-----From: "David W. Gillett"
> I have a problem with my VC++ 1.52 application. I had used the
> Debug option for my project for development and tested the
> application. The application works fine. If I use the Project
> Release Mode, the application suddenly becomes too slow.
Differing behaviour between Debug and Release builds may result
from a couple of different sources:
1. Assertions with needed side-effects.
The evaluation of the expression in an assertion should never be
necessary to the correct/timely functioning of the program. But
there's no way that the compiler can detect or enforce this!
2. Optimization failures.
Some of the optimizations provided by the compiler depend upon
specific assumptions about the code which, again, cannot be verified
by the compiler. If those assumptions are incorrect, unpredictable
results may be obtained. [The compiler code that actually performs
the optimizations is not substantially more bug-free than any other
piece of code of similar complexity, and probably gets exercised less
than many other parts of the compiler. Experiment with the various
optimization options -- starting with "none" -- to determine what
effect each actually has. Use the profiler!]
3. Timing issues.
The specific sluggishness you report is in displaying a window. It
may be that the debug version ran just enoush slower than the release
version for painting to get dispatched on a more timely basis. i.e.
The release version actually runs faster, but updates the screen
later and so *looks* slower. Check out UpdateWindow().
[In a GUI environment, *appearance* and a snappy "feel" may
actually be more important than raw performance.]
4. Poor choice of algorithm.
Debug versions are usually tested against smaller sets of data than
are encountered in the release world. Although the actual
performance details of a given algorithm depend upon the underlying
hardware and platform, algorithms are often characterized by the way
that their performance is affected by changes in data set size.
For example, you won't see much difference between a bubble sort
and a quick sort if you've only got 20 items to sort. If you have
2000, though, you're likely to notice the difference, because the
work done (and thus time taken) by bubble sort increases with the
data size much more quickly than quick sort does.
You may have an algorithm in your code that is very sensitive to
the differences in data between your debug and release testing.
Again, the profiler can help you to identify where the time is being
spent.
In order to use the profiler on your release version, you need to
compile it with debugging information turned on. [Yes, this is
legal!] This will also allow you to run your release build under
CodeView, although optimization and inlining of functions may make
matching source lines to assembly instructions more difficult.
[There's another thought: Inlining of functions may actually make
your release version's working set slightly larger than the debug
version's, but I think this should only have a noticeable affect on
performance if the program is quite small and RAM is in very short
supply. It's unlikely to be the culprit.]
Dave
-----From: VARughese GEOrge
I guess you are using OutputDebugString() call somewhere in your
application!. This could be a problem 'cos OutputDebugString() holds good
even in *release* mode.
Enable Tracing (TRACER.EXE) and Load Debug Windows (DBWIN.EXE) . From
*Options* menu, check *Output to Window* option. Load your application
and after clicking the menu, see if there is any message in the debug
messages window. If yes, then u are using OutputDebugString() call.
(Doing a text search for *OutputDebugString* will be much simpler!! :=)
)
Commenting those calls will solve your problem.
hope this helps!
thanx
vargeo
\\\|///
\\ ~ ~ //
( @ @ )
--------------------------oOOo-(_)-oOOo-------------------------
--
| VARughese GEOrge |
| Snail Mail 1235, Wildwood Ave, Apt#16 |
| Sunnyvale CA - 94089
|
| E-mail vargeo@msn.com, |
| vgeorge@rsc.ramco.com| |
| VoiceMail 510-494-2936 (O) |
| 408-723-9778 (R)
|
| Fax 510-494-2979
|
| home pg: http://ramco_web.ramco.com.vargeo.htm |
------------------------------------Oooo.-----------------------
--------
.oooO ( )
( ) ) /
\ ( (_/
(_)
Kit Kauffmann -- kitk@mudshark.sunquest.com
Monday, January 29, 1996
>Hi all,
>
>I have a problem with my VC++ 1.52 application. I had used the Debug option
>for my project for development and tested the application. The application
>works fine. If I use the Project Release Mode, the application suddenly
>becomes too slow.
>Let me explain.
>
>My application is an MDI application, with a derived CFormView Class as the
>View. I have a VBX Grid Control in the View. When I run the program in the
>Debug Mode, the application works just fine. When I switch to the Release
>Mode, The applications executes. But, when I click on the New ToolBar
>option or select the New option from the File Menu, the View window takes
>a very long time to appear. I am unable to see any problem. I tried to keep
>the Warning Level to 4 and Build the Application. I did not find any error
>except the Conversion from Int to Unsigned int problem.
>
>I am working on Win 95. I am developing a 16-bit application using VC++
>1.52/MFC 2.52.
>
>Can any of u help me out in this?
>
>Thanx in Advance.
>Narayan.
> .\\\.
> ( 0 0 )
> ____________________________.oOo__( ^ )__oOo.____________________________
>(_) \~/ (_)
>| | Narayanan M C email : NARAYAN_M1@blrv1.verifone.com | |
>| | Development Engineer, R&D, | |
>| | Verifone India Pvt. Ltd., | |
>| | Bangalore - 560 001, India. | |
>| | Ph: 91-80-2269920, 2269924 Extn. 3323 | |
>| | 91-80-5541523, 5541524 Extn. 3323 | |
>| | | |
>| | Res: 91-80-3440275 | |
>| | | |
>| | In VuFone Screen Format Generator (VC++ 1.52/MFC 2.52/Win 95) !!! | |
>| |____________________________.oooO___Oooo.____________________________| |
>(_) ( ) ( ) (_)
> \ ( ) /
> \_) (_/
>
>
>
Typically, this is caused by writing to aux: (normally, writing debug-type
output) when there is no target for debug output. The DBWin program which
comes w/ Windows allows you to view and redirect (or shut off) the output,
and the VC++ output windows can accept this output as well.
You can also suppress it completely by adding this to system.ini:
[debug]
OutputTo=NUL ;AUX, LPT1, or whatever
| Вернуться в корень Архива
|