asked on Big differences in speed with which a FORM loads
I've got a FORM in an application which seems to load very slowly by comparison with the other FORMs in the same application.
This is giving me some serious grief because the application also features an anti-piracy software key that's attached to the PC. The application talks to the software key at regular intervals. If the link with the software key drops, then the application crashes. And what seems to be happening here is that loading the FORM is taking so long that the link does indeed drop.
I've looked at what's going on inside the FORM in great detail and can't see anything obvious that would slow it down (particularly during the .INIT() methods). The FORM contains a pageframe, and buttons for [OK] and [Cancel]. The pageframe has four separate tabs. The .SCX file contains 30 records, which seem to correspond to 28 distinct objects.
I've tried embedding some timing points within the FORM. I've tried timing from starting the .LOAD() method to ending the .INIT() method. Running under VFP, that comes out at 0.02 seconds on my laptop (a rather fast Dell XPS machine).
Where's the problem, I hear you cry. Ah well, once I've compiled the application as a .EXE, it slows down. And on my laptop it takes 15.2 seconds. Which is a pretty stupendous slow-down factor.
The target machine, where we want to run the compiled code, isn't as quick as mine, so we could well be talking 30s+, which is getting into the range where the software key will time-out and terminate the application.
Next I tried putting in more intermediate timings. With these in place, it still took 15.2s. But it pointed towards one of the pages being the guilty party, taking all of the time.
There's four objects on that page. None involve any processing as part of their .INIT() method. Anyway, I put in even more intermediate timings for the objects on that particular page.
But now the elapsed time from .LOAD() to .INIT() is a mere 0.19s. The page that I had my suspicions about takes 0.13s of this. And the gap between finishing .INIT() for the last of the four objects and finishing the .INIT() for the page is all of that - the .INIT()s for the objects are all reporting as the same time.
Now, what my question is about is why I should be getting this big variation in the time taken to load the FORM - down from 15.2s to 0.19s. Does anyone have any similar experiences?
This is giving me some serious grief because the application also features an anti-piracy software key that's attached to the PC. The application talks to the software key at regular intervals. If the link with the software key drops, then the application crashes. And what seems to be happening here is that loading the FORM is taking so long that the link does indeed drop.
I've looked at what's going on inside the FORM in great detail and can't see anything obvious that would slow it down (particularly during the .INIT() methods). The FORM contains a pageframe, and buttons for [OK] and [Cancel]. The pageframe has four separate tabs. The .SCX file contains 30 records, which seem to correspond to 28 distinct objects.
I've tried embedding some timing points within the FORM. I've tried timing from starting the .LOAD() method to ending the .INIT() method. Running under VFP, that comes out at 0.02 seconds on my laptop (a rather fast Dell XPS machine).
Where's the problem, I hear you cry. Ah well, once I've compiled the application as a .EXE, it slows down. And on my laptop it takes 15.2 seconds. Which is a pretty stupendous slow-down factor.
The target machine, where we want to run the compiled code, isn't as quick as mine, so we could well be talking 30s+, which is getting into the range where the software key will time-out and terminate the application.
Next I tried putting in more intermediate timings. With these in place, it still took 15.2s. But it pointed towards one of the pages being the guilty party, taking all of the time.
There's four objects on that page. None involve any processing as part of their .INIT() method. Anyway, I put in even more intermediate timings for the objects on that particular page.
But now the elapsed time from .LOAD() to .INIT() is a mere 0.19s. The page that I had my suspicions about takes 0.13s of this. And the gap between finishing .INIT() for the last of the four objects and finishing the .INIT() for the page is all of that - the .INIT()s for the objects are all reporting as the same time.
Now, what my question is about is why I should be getting this big variation in the time taken to load the FORM - down from 15.2s to 0.19s. Does anyone have any similar experiences?
FoxProDell
Last Comment
IainMacb
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks for those.
pcelba : the antivirus is very different on my development laptop and on the production (compiled) machine, so I'd been inclined to discount that.
pcelba : I'll download the process monitor and see what I get. What I'm trying first is to restore the testing conditions that show a 15s delay (before adding more testing and speeding it up).
Olaf : The 'dataenvironment' is empty. I never use this - I'm always opening different files, so I do that in code. This particular FORM doesn't do any processing and doesn't need to talk to any files. What it's doing is allowing the user to set various options via memory variables.
Olaf : a thread for the software key. Sounds like something for the icepack in the darkened room. I'll go and read your links carefully
pcelba : the antivirus is very different on my development laptop and on the production (compiled) machine, so I'd been inclined to discount that.
pcelba : I'll download the process monitor and see what I get. What I'm trying first is to restore the testing conditions that show a 15s delay (before adding more testing and speeding it up).
Olaf : The 'dataenvironment' is empty. I never use this - I'm always opening different files, so I do that in code. This particular FORM doesn't do any processing and doesn't need to talk to any files. What it's doing is allowing the user to set various options via memory variables.
Olaf : a thread for the software key. Sounds like something for the icepack in the darkened room. I'll go and read your links carefully
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
OK, we're back on the case!
And Olaf's suggestion of SET COVERAGE does the business. It turns out that there's a long call to the software key that I forgotten about. And it was tucked away on the .INIT() method for one of the objects, so not easily spotted.
SET COVERAGE is new to me - I've never noticed it before, despite having been using dBASE/Clipper/VFP for more years than I care to remember.
I've split the points - I expect that the suggestion about process monitor would also have picked up the software key call. SET COVERAGE was easier to implement.
And Olaf's suggestion of SET COVERAGE does the business. It turns out that there's a long call to the software key that I forgotten about. And it was tucked away on the .INIT() method for one of the objects, so not easily spotted.
SET COVERAGE is new to me - I've never noticed it before, despite having been using dBASE/Clipper/VFP for more years than I care to remember.
I've split the points - I expect that the suggestion about process monitor would also have picked up the software key call. SET COVERAGE was easier to implement.
In your IDE you likely have data cached more and more, which is a reason the form starts quicker for you. There is no such thing as a compilation downgrade of performance, but indeed a foxpro exe is not faster than runing in the IDE, you always compile and execute objcode.
If you use views, rather open them with nodataonload and in init requery() them parameterised with filtering just the data you want to query.
As you need your app to be responsive to the software key, you better put that into a seperate thread, a timer isn't sufficient for that, as it's delayed, if a query takes longer. But you can spawn an extra thread via http://mtmyvfp.codeplex.com/, which originated here http://blogs.msdn.com/b/calvin_hsia/archive/2006/05/16/599108.aspx
Bye, Olaf.