5

I have a program that I run on multiple network PCs. When I compiled the most recent version, it runs extremely slowly on 2 PCs on the network, but runs fine for everyone else.

This used to happen with my old dev PC when I had an additional 2gb RAM installed. When I would remove the additional 2gb and recompile, it would then work fine for everyone.

Now, I am on a completely new machine and am having the same issue. I've tried to rebuild the project after rebooting, but still have the same issue.

For all other PCs, the program loads in about 3-5 seconds. On these 2 PCs, it takes anywhere from 45 seconds to 1.5 mins to load...

One of the PCs is an older Dell Dimension 8200, but the other is a newer OptiPlex that is identical to several other PCs on the network, so this is what is really making it so confusing.

For now, I've had to revert to the old version so it will run correctly for everyone.

Does anyone have any idea of anything to try?

Thanks in advance!!!


Edit:

Ok, it was an exhausting day yesterday trying various things to solve this issue. Here is what I tried and where the problem begins:

Using the new program

Went back to old versions of all updated components, but still had the same issue

Using the old program

I decided to go back to the drawing board and start from the old version of the application and incrementally add the new features a small piece at a time.

  1. Recompiled the old version using the old components - program works fine
  2. Updated to new DevExpress components - program works fine
  3. Updated to new ESBPCS components - program works fine
  4. Updated to new DeepSoftware components - program works fine

Ok, so now we know there is nothing with the component sets I've updated...

  1. Added 1 image to each of 2 image lists - program works fine
  2. Added new database table - program works fine
  3. Added code to open and close the new table - program works fine
  4. Added new action to action list and added a menu item and toolbar button to new action (action does nothing at this point) - program works fine
  5. Added a new BLANK form to the application and added code to open the new form - BAM!!!

So, adding just one form to the application is what's causing the issue! I removed all the code for the opening of the form, commented out the uses clauses and removed the uses entry from the project source and everything is back to normal!

Anybody have any idea about this?

Thanks!


Edit 2:

For @Warren P - here is my .DPR source:

program Scheduler;

uses
  ExceptionLog,
  Forms,
  SchedulerMainUnit in 'SchedulerMainUnit.pas' {FrmMain},
  SchedulerDBInfoUnit in 'SchedulerDBInfoUnit.pas' {FrmDBInfo},
  SchedulerHistoryUnit in 'SchedulerHistoryUnit.pas' {FrmHistory},
  SchedulerOptionsUnit in 'SchedulerOptionsUnit.pas' {FrmOptions},
  SchedulerExtVersionUnit in 'SchedulerExtVersionUnit.pas' {FrmExtVersion},
  SchedulerSplashUnit in 'SchedulerSplashUnit.pas' {FrmSplash},
  SchedulerInfoUnit in 'SchedulerInfoUnit.pas' {FrmInfo},
  SchedulerShippedUnit in 'SchedulerShippedUnit.pas' {FrmShipped};  {<-- This is the new form with the issue}

{$R *.res}

begin
  Application.Initialize;
  Application.Title := 'SmartWool WIP Scheduling Assistant';
  Application.CreateForm(TFrmMain, FrmMain);
  Application.CreateForm(TFrmDBInfo, FrmDBInfo);
  Application.CreateForm(TFrmHistory, FrmHistory);
  Application.CreateForm(TFrmOptions, FrmOptions);
  Application.CreateForm(TFrmExtVersion, FrmExtVersion);
  Application.Run;
end.

And here is the intialization section of the main form to create the splash:

initialization

FrmSplash:=TFrmSplash.Create(Application);
FrmSplash.Show;
FrmSplash.Refresh;

Edit 3:

Anybody??? Please?

Orionizer
  • 115
  • 1
  • 8
  • I should note that a couple of components have been updated between the versions: DevExpress Build 54 to 55, ESBPCS 5.5.3 to 5.5.4 and DeepSoftware Storage Pack 3.59 to 3.69. – Orionizer Apr 06 '11 at 11:28
  • Does your app establish any network connections when loading? – Roman Yankovsky Apr 06 '11 at 11:39
  • did you step through under a debugger to see what operation is slow? – David Heffernan Apr 06 '11 at 12:09
  • 1
    Try it with the network cable plugged in, and unplugged. On both a fast machine and a slow one. Any correlation there? – Chris Thornton Apr 06 '11 at 12:14
  • 3
    Do you have a networkpath to a non-existent computer in your PATH environment variable? – The_Fox Apr 06 '11 at 12:18
  • Roman: It doesn't establish anything that's not already established (reads a database from a mapped network share). I don't believe that would be an issue anyway, since the old version uses the same database files. – Orionizer Apr 06 '11 at 12:18
  • David, it's not reproducable on my dev machine. – Orionizer Apr 06 '11 at 12:19
  • Chris, I can try this by localizing the databases, but I don't see how it could be anything related to this since the old version works fine (the old version was compiled just a couple of weeks ago). – Orionizer Apr 06 '11 at 12:20
  • The_Fox, I'll check, but I seriously doubt it. – Orionizer Apr 06 '11 at 12:21
  • @Orion then install Delphi on a machine which does show the problem – David Heffernan Apr 06 '11 at 13:08
  • @Orion: Give a try with the remote debugger, you don't have to setup a dev environment in the machine, just install the rdebugger, follow the simple steps to compile, run and attach the remote process and you're debugging over that particular machine. – jachguate Apr 06 '11 at 13:16
  • What's the best way for me to update this with what I've tried today so far? Adding a comment doesn't let me carriage return and I have a LOT of steps to outline for everyone - should I do the "Answer Your Question" or should I "Edit" the original or some other alternative? Sorry, I'm really new at Stack... – Orionizer Apr 06 '11 at 19:32
  • @Orionizer: Update your question. Answers should be used for answers. Just add something like **Edit:** and put your updates there. – The_Fox Apr 06 '11 at 20:45
  • You should change the topic. Your program doesn't "run slow". Instead it's startup is slow. – avra Apr 07 '11 at 07:42
  • @avra, it actually runs slowly as well on these machines. – Orionizer Apr 07 '11 at 11:10
  • Anyone have a chance to look at the edit above? I'm at a complete loss here... – Orionizer Apr 07 '11 at 20:45
  • I have another idea, see my answer. – Warren P Apr 08 '11 at 00:58
  • Have you tried adding some trace messages to the slow unit to find the slow line, and when it runs on the slow computer, you'll have your answer? – Warren P Dec 01 '11 at 01:33
  • Try to copy server file to both good speed and bad speed computer. You can also try to replace places for both computers and see if speed changes when locations are changed and ethernet connections are switched over. If the speed is much different, then you have a network problem. It might be a switch, a cable, or something else. – avra Dec 05 '11 at 15:04

8 Answers8

12

It could be that the program is waiting for timeouts when trying to access resources that are not available on that machine such as network drives or Internet hosts.

Try running Process Monitor when starting up your program and look for file open calls. Filter the output so it only shows your process.

http://technet.microsoft.com/en-us/sysinternals/bb896645

Ville Krumlinde
  • 7,021
  • 1
  • 33
  • 41
6

Performance problems initially can seem very daunting at first.

I have been on many teams where people have tried to guess at a reason for performance problems. This sometimes works, but is far less effective than actually measuring the code.

When reproducible on a development machine, I would recommend a profiler.

There was a previous question that asked about Delphi Profiling tools which has several possible tools you could use.

When you can't reproduce the problem on your development machine, then it becomes a bit more difficult, but not impossible. Typically I have found that problems are related to an application dependency that is different, and not performing well. Understanding the external influences on your application can help pinpoint the problem.

Specifically common external problems in some of my applications.

  • Network
  • Database
  • Application Servers
  • Installation or Data File Location (i.e. Disk Performance)
  • Virus and Malware Scanners
  • Other application interring with yours such as a virus.

To monitor for items related to the network (i.e. Database, web services, etc...) I typically use Wireshark which allows me to see if resources are responding in expected times. My most common problem is poor performing DNS and can found using Wireshark.

You can use the AutoRuns program to determine everything that starts up when your computer does, it's useful in determine differences between machines.

But most of all I have logging that can be turned on in my applications and this allows me to isolate the problem to a specific area of code. This narrowing down to a specific section of code reduces the guessing, and allows you to focus on a few possible problems.

Community
  • 1
  • 1
Robert Love
  • 12,447
  • 2
  • 48
  • 80
  • Thanks for the response. The really strange issue is it even takes SEVERAL seconds for the splash screen to even show up, and the creation of the splash is in the initialization section of the main unit. It is NOT reproducable on my dev machine. I'll check on some of these apps to see if anything shows a problem. – Orionizer Apr 06 '11 at 12:17
  • Then the slowdown is in a module initialization section that runs before your main unit runs. Check this link for helpful tips on debugging your module initialization sections: http://wiert.wordpress.com/2009/10/15/delphi-hardcore-debugging-the-intialization-of-your-app-dlls-and-packages/ – Warren P Apr 07 '11 at 02:08
  • Orionizer, running the remote debugger and simply pausing the app while it's in its startup phase (if that's where the delay is) would let you see where it is / what it's doing. – David Apr 07 '11 at 03:52
4

I created a log function for this that I call at specific places (in your case especially during startup). It adds a timestamp to each log text and stores them in a TMemo that is regularly saved. Not only very helpful when debugging, but may also shed some light on your problem.

Mike Versteeg
  • 1,615
  • 14
  • 28
2

Are you using code signing - ie Microsoft Authenticode? If so, then outdated certificate authorities on the computers can cause significant delays to startup.

HMcG
  • 2,062
  • 4
  • 24
  • 36
2

First, I would try to defragment the hard disk. If still slow, I would check the power supply. Maybe your hard disk are getting insufficient energy.

2

Idea 1:

One reason I have seen for very slow application load time, is when printing or reporting system components like Developer Express Express Print, are in your application.

The problem I saw when using Developer Express Printing components, is that I had an offline or non-responsive network printer in my list of printers (check the control panel printer icon) that was not responding. Some of those Developer Express components seem to read some information from each printer you have installed, and the solution was to go to those clients, and delete old printers from their control panel, that were no longer being used. Each not-responding network printer added up to 60 seconds for a TCP Timeout, to the startup time of my application.

Update - Idea 2:

Download MS DebugView and install it on the machine that runs slowly. Now go back to your main development PC, open the IDE, open your main project file (right click on the project, view project source in project viewer), this will show you the contents of your main project source file (.dpr). go to the main begin....end. block. Now set a breakpoint on the main begin statement, and single step INTO (not OVER) and you will see all the module initialization sections. In each one add this: OutputDebugString('ModuleName').

Now when you run this inside the Delphi Ide you will see messages, and see how far apart they come in, and understand what is taking a long time to initialize. Instead of installing the delphi ide onto the machine that runs slowly, Debug View (which is less than 400kb single executable) will be run, and it will show you these debug messages, along with a nice time display (##.# seconds) for each message.

MS Debug view is here.

Warren P
  • 65,725
  • 40
  • 181
  • 316
  • P, thanks, I had that thought initially as well, but the main form uses a DX Print component as well and the original app doesn't have this problem. See the edit above for more info on what I've found. – Orionizer Apr 07 '11 at 12:18
  • Updated my answer. A little OutputdebugString and MSDebugView is called for. – Warren P Apr 08 '11 at 01:01
  • P, thanks! Will give this a go and let you know what I find! – Orionizer Apr 08 '11 at 11:05
  • Sorry, but I'm a bit confused - When I use F7 to Trace Into on the main form, it doesn't go into the main form source, it just immediately creates my splash and then starts tracing into the rsStorage units. As stated previously, the problem machine takes forever for the splash screen to even show up. What do you think I should do here? (Remember, the splash screen is created in the initialization section of the main form source). If you need, I can post the source for the .DPR and the init section of the main form if that will help. – Orionizer Apr 08 '11 at 11:27
  • I posted the 2 sources above - any idea? – Orionizer Apr 11 '11 at 14:07
2
  1. Check if there is the same antivirus software on those 2 problematic computers. If so, then your Delphi application may match byte pattern used in some virus made in Delphi. Update virus definitions to solve it, or report false alarm to antivirus company, or change antivirus software.
  2. Check if there isn't any printer installed on those 2 problematic computers. If it is so, then add any printer and try again.
avra
  • 3,690
  • 19
  • 19
1

Are you allowing the forms to be constructed on initialization within the DPR source? If so, you may do well to consider whether or not you want those forms sucking up memory the entire time, more-over if you want those forms to be wasting the application's time on load.

A rule of thumb: If the form is used a LOT during the application's execution, allow it to be constructed when the application loads (this will work out faster over-all than constructing the instance "on-demand"). If the form is not used very often at all (for example, a Dialog or an About Box), delete the "Application.CreateForm" line from the DPR source, and instead construct your instance on request...

var
  LForm: TfrmAbout;
begin
  Application.CreateForm(LForm, TfrmAbout);
  try
    LForm.ShowModal;
  finally
    LForm.Free;
  end;
end;

Now that form (which may not even be displayed during the program's execution) is not sucking up system resources, and will not slow down the application's load time.

It may not solve your problem 100%, but it should certainly help!

LaKraven
  • 5,804
  • 2
  • 23
  • 49
  • Thanks for the answer, but I've already tried that (with the new form). In fact, I already had done that since the new form had a cxGrid on it connected to the new database (read only). I had removed the creation from the .dpr and created the new form only when the action was called. – Orionizer Apr 12 '11 at 11:00