Re: What is the execution "debug.print" command after compile?
From: Tony Proctor (tony_proctor_at_aimtechnology_NoMoreSPAM_.com)
Date: 10/11/04
- Next message: Top Spin: "Re: Dim v Private v Public v Global & Const"
- Previous message: Sam Low: "How to get random number at same time each day?"
- In reply to: Duane Bozarth: "Re: What is the execution "debug.print" command after compile?"
- Next in thread: Duane Bozarth: "Re: What is the execution "debug.print" command after compile?"
- Reply: Duane Bozarth: "Re: What is the execution "debug.print" command after compile?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 11 Oct 2004 15:55:10 +0100
It feels as though what's happening is that it's somehow relying on the
compiler's normal removal of dead code to get rid of Debug.Print statements
(i.e. the removal of code that can never be reached, or that does not have
any useful effect), and that this being tripped up by the procedure calls.
Procedure calls may have side-effects unknown to the compiler, and so there
are situations where they would have to be left in tact.
For instance, consider the case of a duplicated assignment:
z = x + y1
z = x + y2
A reasonable compiler would remove one of these because the effect is not
useful. Similarly if the destination variable is never used again.
However, if the statements were:
z = x() + y1
z = x() + y2
then x must be called twice because of any possible side effects it may
have. This is a pretty hard-and-fast rule of code optimisation
Tony Proctor
"Duane Bozarth" <dp_bozarth@swko.dot.net> wrote in message
news:416A99DA.54419655@swko.dot.net...
> Bonj wrote:
> >
> > I also tried another test, but it failed. That was to make an exe with
> > nothing other than a Debug.Print statement in and run "fc" from a DOS
box
> > (file compare) to compare it to an exe with absolutely nothing in at
all.
> > However if you compile an exe with absolutely nothing in twice, it still
> > isn't the same!
> >
> > Although - it's the same size. Try it - do you get 16,384 bytes? (Just
one
> > module, no forms, with just a blank sub main, compiled to native code.)
> > When Debug.Print "hello" is in it, I still get 16,384 bytes.
> >
> > The conclusion I personally draw from this is that the VB6 team have
been
> > reasonably effective in parsing out Debug.Print statements from compiled
> > exes, but not 100% effective, namely when proc. calls are involved.
> > Presumably this is something to do with the way the linker operates?
>
> Wrong conclusion based on the size argument...the VB executables are
> padded to next block size...if you look at your executable with a dump
> utility, you'll see the back end is simply garbage (or empty, depending
> on the age/version of your OS).
>
> The "reasonably effective parsing" part is apparently true, but it would
> appear to be a bug in the compiler assuming there would be no debug
> statement following a procedure call on a source line based on Rick's
> tests...
- Next message: Top Spin: "Re: Dim v Private v Public v Global & Const"
- Previous message: Sam Low: "How to get random number at same time each day?"
- In reply to: Duane Bozarth: "Re: What is the execution "debug.print" command after compile?"
- Next in thread: Duane Bozarth: "Re: What is the execution "debug.print" command after compile?"
- Reply: Duane Bozarth: "Re: What is the execution "debug.print" command after compile?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
