Home > Archive > Visual Basic > September 2004 > What make EXE slower that VBP?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What make EXE slower that VBP?
|
|
| Stan Hilliard 2004-09-20, 3:56 pm |
| VB6 - I made a [help][about] form which is five time slower to
load/show from the compiled EXE than in the IDE.
IDE -- 1 second
EXE -- 5 seconds
What could be the reason that the compiled program would execute more
slowly than in the IDE?
Here is the code in frmabout :
====start
Option Explicit
Private Sub Form_Load()
Static ExpireDate As Date
Static FirstRunDate As String
lblTitle.Caption = App.TITLE & " - Version " & App.Major & "." &
App.Minor & "." & App.Revision
If MDIForm1.IsLicensed Then
lblUser = "Licenced to: " & MDIForm1.UserNameAndCompany _
& vbNewLine & "Serial Number:" & MDIForm1.SerialNumber
Else
lblUser = "Not licensed, used by: " &
MDIForm1.UserNameAndCompany
End If
With MDIForm1
If .IsTimed Then
ExpireDate = CDate(.FirstRunDate) + .TrialDaysAllowed
If Date <= ExpireDate Then 'not expired.
lblTimedOut = "This " & .TrialName & " was installed
on " & .FirstRunDate _
& " and its " & .TrialDaysAllowed & " day trial will
expire after " _
& ExpireDate - CDate(.FirstRunDate) & " days on " &
ExpireDate
Else 'expired.
lblTimedOut = "This " & .TrialName & " expired on " &
ExpireDate & ", " _
& .TrialDaysAllowed & " after its first run on " &
..FirstRunDate
End If
Else 'is not timed.
lblTimedOut = "Permanently assigned"
End If
End With
lblDescription.Caption = _
"TP105 designs acceptance sampling plans for attributes." _
& vbNewLine & "using the two-point method to specify an oc
curve and" _
& vbNewLine & "calculates its fixed-n and sequential decision
rules."
lblDisclaimer = "Copyright (c) 2004 H & H Servicco Corp." _
& vbNewLine & "All rights reserved." _
& vbNewLine & "www.samplingplans.com"
End Sub
Private Sub cmdOK_Click()
Unload Me
End Sub
====end
Information will be appreciated.
Stan Hilliard
| |
| Tim Baur 2004-09-20, 3:56 pm |
| That's a lot of code to look through. Rather than try to figure it out
yourself, why don't you just log code execution in the sub and narrow it
down?
Declare this variable and note the time at the start of the sub
Dim dStart as Double
dStart = Timer
Around halfway through the sub, place this line
Msg dStart - Timer
If there's an appriciable difference between the IDE and the compiled
execution, you'll know the problem lies in the first half of the sub.
Otherwise, it's in the second. You can keep narrowing it down from
there.
Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
news:la0uk0dmthdedcjhrvem69n8dh7h7nsd1i@
4ax.com:
> VB6 - I made a [help][about] form which is five time slower to
> load/show from the compiled EXE than in the IDE.
>
> IDE -- 1 second
> EXE -- 5 seconds
>
> What could be the reason that the compiled program would execute more
> slowly than in the IDE?
>
> Here is the code in frmabout :
> ====start
> Option Explicit
>
> Private Sub Form_Load()
> Static ExpireDate As Date
> Static FirstRunDate As String
> lblTitle.Caption = App.TITLE & " - Version " & App.Major & "." &
> App.Minor & "." & App.Revision
>
> If MDIForm1.IsLicensed Then
> lblUser = "Licenced to: " & MDIForm1.UserNameAndCompany _
> & vbNewLine & "Serial Number:" & MDIForm1.SerialNumber
> Else
> lblUser = "Not licensed, used by: " &
> MDIForm1.UserNameAndCompany
> End If
>
> With MDIForm1
> If .IsTimed Then
> ExpireDate = CDate(.FirstRunDate) + .TrialDaysAllowed
> If Date <= ExpireDate Then 'not expired.
> lblTimedOut = "This " & .TrialName & " was installed
> on " & .FirstRunDate _
> & " and its " & .TrialDaysAllowed & " day trial will
> expire after " _
> & ExpireDate - CDate(.FirstRunDate) & " days on " &
> ExpireDate
> Else 'expired.
> lblTimedOut = "This " & .TrialName & " expired on " &
> ExpireDate & ", " _
> & .TrialDaysAllowed & " after its first run on " &
> .FirstRunDate
> End If
> Else 'is not timed.
> lblTimedOut = "Permanently assigned"
> End If
> End With
>
> lblDescription.Caption = _
> "TP105 designs acceptance sampling plans for attributes." _
> & vbNewLine & "using the two-point method to specify an oc
> curve and" _
> & vbNewLine & "calculates its fixed-n and sequential decision
> rules."
>
> lblDisclaimer = "Copyright (c) 2004 H & H Servicco Corp." _
> & vbNewLine & "All rights reserved." _
> & vbNewLine & "www.samplingplans.com"
>
> End Sub
>
> Private Sub cmdOK_Click()
> Unload Me
> End Sub
>
> ====end
>
> Information will be appreciated.
> Stan Hilliard
>
>
| |
| Stan Hilliard 2004-09-20, 3:56 pm |
| The EXE and IDE versions were both fast when I added the timer code.
Then I took the timer code out and they were still fast.
I am puzzled because I had verified the problem 5 or 6 times,
including with recompiling.
Stan Hilliard
On Mon, 20 Sep 2004 09:55:12 -0700, Tim Baur
<trbo20@disregard_yahoo.com> wrote:
[color=darkred]
>That's a lot of code to look through. Rather than try to figure it out
>yourself, why don't you just log code execution in the sub and narrow it
>down?
>
>Declare this variable and note the time at the start of the sub
>
>Dim dStart as Double
>dStart = Timer
>
>
>Around halfway through the sub, place this line
>
>Msg dStart - Timer
>
>If there's an appriciable difference between the IDE and the compiled
>execution, you'll know the problem lies in the first half of the sub.
>Otherwise, it's in the second. You can keep narrowing it down from
>there.
>
>
>
>
>Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
> news:la0uk0dmthdedcjhrvem69n8dh7h7nsd1i@
4ax.com:
>
| |
| Tim Baur 2004-09-20, 3:56 pm |
| Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
news:di9uk09hd8b43rnhfheh92tjpdrumsmqf9@
4ax.com:
> The EXE and IDE versions were both fast when I added the timer code.
>
> Then I took the timer code out and they were still fast.
???
Oh well, at least it's fixed.
| |
| Jeff Johnson [MVP: VB] 2004-09-20, 8:55 pm |
|
"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
news:di9uk09hd8b43rnhfheh92tjpdrumsmqf9@
4ax.com...
> The EXE and IDE versions were both fast when I added the timer code.
>
> Then I took the timer code out and they were still fast.
>
> I am puzzled because I had verified the problem 5 or 6 times,
> including with recompiling.
Welcome to the wonderful world of programming. Sacrifice a chicken to the
program in the hopes that it never does this again and move on....
| |
| Stan Hilliard 2004-09-21, 3:55 pm |
| I found the culprit. The delayed opening of frmAbout only happens when
my anti-virus program (F-Prot) is running in the background -- in
"real time protector" mode.
The frmAbout is so small that I don't understand why it should take 5
seconds anyway, but it does from the EXE but not from the IDE.
load/show frmAbout from IDE -- 1 second
Load/show the EXE -- 3 seconds
load/show frmAbout from Exe -- 5 seconds
Can anyone explain why the anti-virus would effect slow the EXE but
not the IDE?
Also, what could be the reason why would it take more time to
load/show frmAbout from the EXE (5 seconds) than to load/show the
whole EXE (3 seconds)?
Stan Hilliard
On Mon, 20 Sep 2004 11:45:25 -0500, Stan Hilliard
<usenetreplyMS@samplingplansNOTSPAM.com> wrote:
>VB6 - I made a [help][about] form which is five time slower to
>load/show from the compiled EXE than in the IDE.
>
>IDE -- 1 second
>EXE -- 5 seconds
>
>What could be the reason that the compiled program would execute more
>slowly than in the IDE?
>
>Here is the code in frmabout :
>====start
>Option Explicit
>
>Private Sub Form_Load()
> Static ExpireDate As Date
> Static FirstRunDate As String
> lblTitle.Caption = App.TITLE & " - Version " & App.Major & "." &
>App.Minor & "." & App.Revision
>
> If MDIForm1.IsLicensed Then
> lblUser = "Licenced to: " & MDIForm1.UserNameAndCompany _
> & vbNewLine & "Serial Number:" & MDIForm1.SerialNumber
> Else
> lblUser = "Not licensed, used by: " &
>MDIForm1.UserNameAndCompany
> End If
>
> With MDIForm1
> If .IsTimed Then
> ExpireDate = CDate(.FirstRunDate) + .TrialDaysAllowed
> If Date <= ExpireDate Then 'not expired.
> lblTimedOut = "This " & .TrialName & " was installed
>on " & .FirstRunDate _
> & " and its " & .TrialDaysAllowed & " day trial will
>expire after " _
> & ExpireDate - CDate(.FirstRunDate) & " days on " &
>ExpireDate
> Else 'expired.
> lblTimedOut = "This " & .TrialName & " expired on " &
>ExpireDate & ", " _
> & .TrialDaysAllowed & " after its first run on " &
>.FirstRunDate
> End If
> Else 'is not timed.
> lblTimedOut = "Permanently assigned"
> End If
> End With
>
> lblDescription.Caption = _
> "TP105 designs acceptance sampling plans for attributes." _
> & vbNewLine & "using the two-point method to specify an oc
>curve and" _
> & vbNewLine & "calculates its fixed-n and sequential decision
>rules."
>
> lblDisclaimer = "Copyright (c) 2004 H & H Servicco Corp." _
> & vbNewLine & "All rights reserved." _
> & vbNewLine & "www.samplingplans.com"
>
>End Sub
>
>Private Sub cmdOK_Click()
> Unload Me
>End Sub
>
>====end
>
>Information will be appreciated.
>Stan Hilliard
| |
| Ken Halter 2004-09-21, 3:55 pm |
| Stan Hilliard wrote:
> Can anyone explain why the anti-virus would effect slow the EXE but
> not the IDE?
>
> Also, what could be the reason why would it take more time to
> load/show frmAbout from the EXE (5 seconds) than to load/show the
> whole EXE (3 seconds)?
>
> Stan Hilliard
Any scripting going on? FSO maybe? Registry access?
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..
| |
| Dan Barclay 2004-09-21, 8:55 pm |
| Problems that mysteriously disappear will mysteriously reappear.
You can quote me on that <vbg>.
Later,
Dan
"Jeff Johnson [MVP: VB]" <i.get@enough.spam> wrote in message
news:uex39q0nEHA.1712@tk2msftngp13.phx.gbl...
>
> "Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
> news:di9uk09hd8b43rnhfheh92tjpdrumsmqf9@
4ax.com...
>
>
> Welcome to the wonderful world of programming. Sacrifice a chicken to the
> program in the hopes that it never does this again and move on....
>
>
| |
|
| I gotta go with Dan on this one, Jeff. That's hardly the best advice you've
ever given (but I assume it was more in jest than anything else).
Mike
"Dan Barclay" <Dan@MVPs.org> wrote in message
news:expUcYBoEHA.608@TK2MSFTNGP09.phx.gbl...
> Problems that mysteriously disappear will mysteriously reappear.
>
> You can quote me on that <vbg>.
>
> Later,
> Dan
>
>
> "Jeff Johnson [MVP: VB]" <i.get@enough.spam> wrote in message
> news:uex39q0nEHA.1712@tk2msftngp13.phx.gbl...
message[color=darkred]
the[color=darkred]
>
>
| |
|
|
"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
news:3mq0l0dn1153051gen320bhpq9oespe26f@
4ax.com...
> I found the culprit. The delayed opening of frmAbout only happens when
> my anti-virus program (F-Prot) is running in the background -- in
> "real time protector" mode.
>
> The frmAbout is so small that I don't understand why it should take 5
> seconds anyway, but it does from the EXE but not from the IDE.
Well, that makes perfect sense to me. Your anti-virus software is scanning
the EXE. It's not scanning anything when you run your project within the
IDE (probably vb6.exe when you start VB, but that's it). 5 seconds seems
excessive to me, but if your antivirus sofware is doing heuristics and
whatever else, it's conceivable I suppose. It might also have to do with
whatever your frmAbout module does. For example, does it utilize other
files to obtain information? If so, those are probably getting checked by
your antivius software as well.
Mike
| |
| Dan Barclay 2004-09-22, 3:55 pm |
| Hehe, I wasn't complaining about Jeff's advice. I'm just expressing
experience<g>.
I've had to "move on" myself before. Sometimes that's what you do, until it
mysteriously comes back and you can ID it. You've gotta prioritize tasks,
including bugs. You *can't* kill 'em all even when you want to<sigh>. I
hate it when that happens.
Dan
"MikeD" <nobody@nowhere.edu> wrote in message
news:ePl68UDoEHA.3428@TK2MSFTNGP11.phx.gbl...
> I gotta go with Dan on this one, Jeff. That's hardly the best advice
you've
> ever given (but I assume it was more in jest than anything else).
>
> Mike
>
>
>
>
>
> "Dan Barclay" <Dan@MVPs.org> wrote in message
> news:expUcYBoEHA.608@TK2MSFTNGP09.phx.gbl...
> message
> the
>
>
| |
| Stan Hilliard 2004-09-24, 3:55 am |
| On Tue, 21 Sep 2004 11:16:50 -0700, Ken Halter
<Ken_Halter@Use_Sparingly_Hotmail.com> wrote:
>Stan Hilliard wrote:
>
>Any scripting going on? FSO maybe? Registry access?
No scripting. No FSO. The MDI accesses the registry when it loads, but
frmAbout does not.
Stan Hilliard
| |
| Stan Hilliard 2004-09-24, 3:55 am |
| On Tue, 21 Sep 2004 19:58:08 -0400, "MikeD" <nobody@nowhere.edu>
wrote:
>
>"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
> news:3mq0l0dn1153051gen320bhpq9oespe26f@
4ax.com...
>
>
>Well, that makes perfect sense to me. Your anti-virus software is scanning
>the EXE. It's not scanning anything when you run your project within the
>IDE (probably vb6.exe when you start VB, but that's it).
The EXE starts quickly and brings up the MDI in 3 seconds.
>5 seconds seems
>excessive to me, but if your antivirus sofware is doing heuristics and
>whatever else, it's conceivable I suppose. It might also have to do with
>whatever your frmAbout module does. For example, does it utilize other
>files to obtain information? If so, those are probably getting checked by
>your antivius software as well.
>Mike
All frmAbout does is to read a few string variables from the MDI and
displays the data.
Stan Hilliard
| |
| Stan Hilliard 2004-09-24, 3:55 am |
| On Tue, 21 Sep 2004 13:12:09 -0500, Stan Hilliard
<usenetreplyMS@samplingplansNOTSPAM.com> wrote:
>I found the culprit. The delayed opening of frmAbout only happens when
>my anti-virus program (F-Prot) is running in the background -- in
>"real time protector" mode.
I found the line of code that makes the five second delay -- running
the EXE, anti-virus on.
Private Sub Form_Load() 'frmAbout.
Static ExpireDate As Date
Dim dStart As Double
dStart = Timer
MsgBox "0: " & Format(Timer - dStart, "###0.000000") '=003 sec.
dStart = Timer
lblTitle.Caption = App.TITLE _
& " - Version " & App.Major _
& "." & App.Minor _
& "." & App.Revision
MsgBox "1: " & Format(Timer - dStart, "###0.000000")
'The message box says 5.767 seconds
Why would the virus scanner behave differently toward the VB App
object than it would toward any other of the many VB objects used by
my program?
Stan Hilliard
[color=darkred]
>The frmAbout is so small that I don't understand why it should take 5
>seconds anyway, but it does from the EXE but not from the IDE.
>
>load/show frmAbout from IDE -- 1 second
>
>Load/show the EXE -- 3 seconds
>
>load/show frmAbout from Exe -- 5 seconds
>
>Can anyone explain why the anti-virus would effect slow the EXE but
>not the IDE?
>
>Also, what could be the reason why would it take more time to
>load/show frmAbout from the EXE (5 seconds) than to load/show the
>whole EXE (3 seconds)?
>
>Stan Hilliard
>
>On Mon, 20 Sep 2004 11:45:25 -0500, Stan Hilliard
><usenetreplyMS@samplingplansNOTSPAM.com> wrote:
>
| |
| Tim Baur 2004-09-24, 3:55 pm |
| Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
news:fms6l0pvt6la5oebn9q0csg7h24ltiaeku@
4ax.com:
>
> No scripting. No FSO. The MDI accesses the registry when it loads, but
> frmAbout does not.
>
> Stan Hilliard
>
Try isolating your frmAbout in a new project and see if it alone is
responsible, or if it's a combination of factors.
| |
|
| It's possible the App object is pulling the version directly from the exe
which is probally being checked by the scanner.
"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
news:pia7l0d624cp53er48nd4lidc20ep9qbte@
4ax.com...
> On Tue, 21 Sep 2004 13:12:09 -0500, Stan Hilliard
> <usenetreplyMS@samplingplansNOTSPAM.com> wrote:
>
>
> I found the line of code that makes the five second delay -- running
> the EXE, anti-virus on.
>
> Private Sub Form_Load() 'frmAbout.
> Static ExpireDate As Date
> Dim dStart As Double
>
> dStart = Timer
> MsgBox "0: " & Format(Timer - dStart, "###0.000000") '=003 sec.
>
> dStart = Timer
> lblTitle.Caption = App.TITLE _
> & " - Version " & App.Major _
> & "." & App.Minor _
> & "." & App.Revision
>
> MsgBox "1: " & Format(Timer - dStart, "###0.000000")
> 'The message box says 5.767 seconds
>
> Why would the virus scanner behave differently toward the VB App
> object than it would toward any other of the many VB objects used by
> my program?
>
> Stan Hilliard
>
>
| |
| Stan Hilliard 2004-09-25, 3:55 pm |
| On Fri, 24 Sep 2004 06:42:29 -0700, Tim Baur
<trbo20@disregard_yahoo.com> wrote:
>Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
> news:fms6l0pvt6la5oebn9q0csg7h24ltiaeku@
4ax.com:
>
>
>Try isolating your frmAbout in a new project and see if it alone is
>responsible, or if it's a combination of factors.
The new project runs OK -- without the 5 second delay when the
anti-virus is on..
I built the new project containing just an MDI with a [help][About]
menu. I copied the original frmAbout to the new project.
I had to add some code to the MDI with some "Property Gets" because
frmAbout gets some string values from the MDI.
The values that frmAbout gets from MDI are either assigned in the MDI
from code or read from the registry by the MDI during MDIForm_load.
References: The references are the same for both projects.
Components:
The new test project contains no references.
My application contains:
Microsoft Common Dialog Control 6.0
Microsoft Rich Textbox Control (SP4)
Microsoft Tabbed Dialog Control 6.0
Microsoft Windows Common Control 6.0 (SP4)
In the application, I was able to identify which properties of the App
object that interact with the virus-scanner:
App.TITLE -- fast, no problem
App.Major - slow, 2.6 sec.
App.Minor - slow, 2.6 sec
App.Revision - slow, 2.6 sec.
Another weird effect of frmAbout in my application:
The time to obtain a value like App.Major changes depending on how
many similar assignments exist in frmAbout. The 2.6 second timings
above were made while a second set of assignments was below it in
code. When I commented the second code the 2.6 became 3.7!
Then, commenting the App.minor and App.Revision, the App.Major time
was 3.2 seconds. There seems to be no predictability when I add or
subtract code, as to whether the times will go up or down.
Since App.TITLE is not effected, it seems that the problem is related
only to certain properties of the App object, and there is an
interaction between accessing those properties and my virus scanner.
And since frmAbout works OK in my test project, there is a third,
unknown, factor in my application.
I'm still stuck, Stan Hilliard
| |
| Tim Baur 2004-09-26, 3:55 am |
| Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
news:o95bl0trgnit9veuan468fjamde1iudve8@
4ax.com:
> In the application, I was able to identify which properties of the App
> object that interact with the virus-scanner:
>
> App.TITLE -- fast, no problem
> App.Major - slow, 2.6 sec.
> App.Minor - slow, 2.6 sec
> App.Revision - slow, 2.6 sec.
How did you identify this?
Have you tried putting a dummy frmAbout in your project to see if it is
really the problem?
I have to say, I'm running out of ideas. Sounds like you're on the right
track to figuring it out. Just keep sysematically isolating and
elimating variables until you have it narrowed down.
| |
| Stan Hilliard 2004-09-26, 8:55 pm |
| On Sat, 25 Sep 2004 20:21:20 -0700, Tim Baur
<trbo20@DISREGARD_Yahoo.com> wrote:
>Stan Hilliard <usenetreplyMS@samplingplansNOTSPAM.com> wrote in
> news:o95bl0trgnit9veuan468fjamde1iudve8@
4ax.com:
>
>
>How did you identify this?
I separated the terms in this original line of code that caused the
delay:
dStart = Timer
lblTitle.Caption = App.TITLE _
& " - Version " & App.Major _
& "." & App.Minor _
& "." & App.Revision
MsgBox "1: " & Format(Timer - dStart, "###0.000000")
into four separate timed lines.
>Have you tried putting a dummy frmAbout in your project to see if it is
>really the problem?
Good point.
I removed frmAbout from the project, renamed the frm and frx files,
and added a new [project][add form] [new][about dialog]
I saved, compiled, ran the EXE, and timed [help][About]. It took 11
seconds to show frmAbout. It took similarly long time for the [System
Info..] button to show its window.
So it looks like the problem is a three-way interaction between the
frmAbout that the VBIDE generates, F-Prot antivirus, and a third
factor = "my application".
Next I commented this one line in the newly generated frmabout :
lblVersion.Caption = "Version " & App.Major & "." & App.Minor & "." &
App.Revision
After re-compiling, my application, [help][About] showed FrmAbout
almost instantaneously. The same for [System Info...]
Next, thinking that the problem might be something unique to the
[about dialog] form, I made a new blank form, added a new label
lblVersion, and added the offending line of code to Form_Load. It had
the long delay, indicating that it was the code and not the form.
Next I copied that offending line to the frmAbout that had worked OK
in the test project. I added a label lblVersion (because I had
previously renamed the original label by that name.) I compiled it.
frmAbout loaded almost instantly. OK. So the bad code runs OK in the
test project but not in my application.
To be sure that I had exhausted all possibilities, I copied the "bad"
line of code that works in the test project back to the new frmAbout
in my application. It still causes the delay there.
I found an old application that I hadn't compiled since February 2001
and added the VBIDE's frmAbout dialog. It contained the "bad" line of
code, but it loads fast.
I had the same good result when I added a frmAbout dialog to a more
recent project.
>I have to say, I'm running out of ideas. Sounds like you're on the right
>track to figuring it out. Just keep sysematically isolating and
>elimating variables until you have it narrowed down.
I would sure like to get a clue as to what to look for based on theory
because it seems like a massive job to compare two whole projects.
Meanwhile I have set the cursor to hourglass during the delay.
Stan Hilliard
| |
| Steve Barnett 2004-09-27, 8:55 am |
| This will sound utterly stupid, but does it take as long if you rename the
exe? Could it be that something about the name of the exe is causing your
anti-virus software to virus scan the exe every time it's opened (such as
when retrieving the version information).
Steve
"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
news:229el05untlmsm17pn5atgkr9b1sk2jpcc@
4ax.com...
> On Sat, 25 Sep 2004 20:21:20 -0700, Tim Baur
> <trbo20@DISREGARD_Yahoo.com> wrote:
>
>
> I separated the terms in this original line of code that caused the
> delay:
>
> dStart = Timer
> lblTitle.Caption = App.TITLE _
> & " - Version " & App.Major _
> & "." & App.Minor _
> & "." & App.Revision
> MsgBox "1: " & Format(Timer - dStart, "###0.000000")
>
> into four separate timed lines.
>
>
> Good point.
> I removed frmAbout from the project, renamed the frm and frx files,
> and added a new [project][add form] [new][about dialog]
>
> I saved, compiled, ran the EXE, and timed [help][About]. It took 11
> seconds to show frmAbout. It took similarly long time for the [System
> Info..] button to show its window.
>
> So it looks like the problem is a three-way interaction between the
> frmAbout that the VBIDE generates, F-Prot antivirus, and a third
> factor = "my application".
>
> Next I commented this one line in the newly generated frmabout :
>
> lblVersion.Caption = "Version " & App.Major & "." & App.Minor & "." &
> App.Revision
>
> After re-compiling, my application, [help][About] showed FrmAbout
> almost instantaneously. The same for [System Info...]
>
> Next, thinking that the problem might be something unique to the
> [about dialog] form, I made a new blank form, added a new label
> lblVersion, and added the offending line of code to Form_Load. It had
> the long delay, indicating that it was the code and not the form.
>
> Next I copied that offending line to the frmAbout that had worked OK
> in the test project. I added a label lblVersion (because I had
> previously renamed the original label by that name.) I compiled it.
> frmAbout loaded almost instantly. OK. So the bad code runs OK in the
> test project but not in my application.
>
> To be sure that I had exhausted all possibilities, I copied the "bad"
> line of code that works in the test project back to the new frmAbout
> in my application. It still causes the delay there.
>
> I found an old application that I hadn't compiled since February 2001
> and added the VBIDE's frmAbout dialog. It contained the "bad" line of
> code, but it loads fast.
>
> I had the same good result when I added a frmAbout dialog to a more
> recent project.
>
>
> I would sure like to get a clue as to what to look for based on theory
> because it seems like a massive job to compare two whole projects.
>
> Meanwhile I have set the cursor to hourglass during the delay.
>
> Stan Hilliard
>
>
| |
| Stan Hilliard 2004-09-27, 3:55 pm |
| On Mon, 27 Sep 2004 11:48:28 +0100, "Steve Barnett"
<noname@nodomain.com> wrote:
>This will sound utterly stupid, but does it take as long if you rename the
>exe? Could it be that something about the name of the exe is causing your
>anti-virus software to virus scan the exe every time it's opened (such as
>when retrieving the version information).
>
>Steve
I renamed it from TP105Assembly.exe to NewName.exe.
It didn't make any difference.
New Clue:
However, in doing this I noticed that renaming the EXE takes almost no
time, whereas right clicking it takes 14 seconds for the menu to come
up. This while the virus scanner is running. Without the anti-virus
running, the right click menu comes up almost instantaneously.
Another test in D:\Program Files\Microsoft Visual Studio\VB98:
VB6.exe, 8420 KB, 9/15/00 -- the Rgt-Clk menu was ALMOST INSTANT.
Then selecting "scan with F-Prot anti-virus" from the Rgt-click menu,
it took 8 seconds to scan VB6.exe, but the F-Prot message box said 2
seconds. The "scan with F-Prot anti-virus" results were the same
regardless whether the anti-virus program Realtime was running.
VISDATA.EXE, 772 KB, 6/18/98 -- the Rgt-Clk menu to 16 seconds.
Then selecting "scan with F-Prot anti-virus" from the Rgt-click menu,
it took 8 seconds VISDATA.EXE, but the F-Prot message box said 2
seconds. The "scan with F-Prot anti-virus" results were the same
regardless whether the anti-virus program Realtime was running.
What is this data saying?
Stan Hilliard
>"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
> news:229el05untlmsm17pn5atgkr9b1sk2jpcc@
4ax.com...
>
| |
| Steve Barnett 2004-09-28, 8:55 am |
|
> What is this data saying?
What it's saying to me is:
a) Check for an upgrade to F-prot - it might be a bug
b) Contact F-Prot support and see what they suggest to fix performance
problems - it' obviously nothing specific in your program
c) Ditch F-Prot for something else
Steve
"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
news:2bdgl0lsl0o074i7uenr39qmpms4bben34@
4ax.com...
> On Mon, 27 Sep 2004 11:48:28 +0100, "Steve Barnett"
> <noname@nodomain.com> wrote:
>
>
> I renamed it from TP105Assembly.exe to NewName.exe.
>
> It didn't make any difference.
>
> New Clue:
> However, in doing this I noticed that renaming the EXE takes almost no
> time, whereas right clicking it takes 14 seconds for the menu to come
> up. This while the virus scanner is running. Without the anti-virus
> running, the right click menu comes up almost instantaneously.
>
> Another test in D:\Program Files\Microsoft Visual Studio\VB98:
>
> VB6.exe, 8420 KB, 9/15/00 -- the Rgt-Clk menu was ALMOST INSTANT.
>
> Then selecting "scan with F-Prot anti-virus" from the Rgt-click menu,
> it took 8 seconds to scan VB6.exe, but the F-Prot message box said 2
> seconds. The "scan with F-Prot anti-virus" results were the same
> regardless whether the anti-virus program Realtime was running.
>
> VISDATA.EXE, 772 KB, 6/18/98 -- the Rgt-Clk menu to 16 seconds.
>
> Then selecting "scan with F-Prot anti-virus" from the Rgt-click menu,
> it took 8 seconds VISDATA.EXE, but the F-Prot message box said 2
> seconds. The "scan with F-Prot anti-virus" results were the same
> regardless whether the anti-virus program Realtime was running.
>
> What is this data saying?
>
> Stan Hilliard
>
>
>
| |
| Stan Hilliard 2004-09-28, 3:55 pm |
| On Tue, 28 Sep 2004 08:52:12 +0100, "Steve Barnett"
<noname@nodomain.com> wrote:
>
>
>What it's saying to me is:
>
>a) Check for an upgrade to F-prot - it might be a bug
>b) Contact F-Prot support and see what they suggest to fix performance
>problems - it' obviously nothing specific in your program
>c) Ditch F-Prot for something else
>
>Steve
I sent F-Prot support the additional facts about the problem
yesterday and about this thread.
A support person replied that she is looking at it.
Stan Hilliard
>"Stan Hilliard" <usenetreplyMS@samplingplansNOTSPAM.com> wrote in message
> news:2bdgl0lsl0o074i7uenr39qmpms4bben34@
4ax.com...
>
| |
| Stan Hilliard 2004-09-29, 3:55 am |
|
On Tue, 28 Sep 2004 14:18:57 -0500, Stan Hilliard
<usenetreplyMS@samplingplansNOTSPAM.com> wrote:
>On Tue, 28 Sep 2004 08:52:12 +0100, "Steve Barnett"
><noname@nodomain.com> wrote:
>
>I sent F-Prot support the additional facts about the problem
>yesterday and about this thread.
>
>A support person replied that she is looking at it.
>
>Stan Hilliard
In my application, I have fixed the symptom by not calling App.Major,
App.Minor, and App.Revision -- but instead made the version
information properties of MDIForm1, accessible through Property Get.
The program now starts very fast and frmAbout loads very fast.
The extremely long delay when I right click some EXE files in Windows
Explorer still occurs as previously when the "real-time protector"
virus scanner is running.
Stan Hilliard
[color=darkred]
|
|
|
|
|