The program runs slowly on multiple computers

Question

I have a program that I run on several network computers. When I compiled the latest version, it works very slowly on two PCs on the network, but works great for everyone else.

This happened to my old computer when I had 2 GB of RAM. When I remove the extra 2gb and recompile it will work just fine for everyone.

Now I am on a completely new machine and I have the same problem. I tried rebuilding the project after rebooting, but still have the same problem.

For all other PCs, the program loads in about 3-5 seconds. These two PCs take from 45 seconds to 1.5 minutes to boot ...

One of the computers is the older Dell Dimension 8200, but the other is the new OptiPlex, which is identical to several other computers on the network, so this really makes it so confusing.

Now I had to go back to the old version so that it worked correctly for everyone.

Does anyone have an idea to try something?

Thanks in advance!

---

Edit:

Well, yesterday was a grueling day trying to solve this problem. Here is what I tried and where the problem starts:

Using a new program

Reverted to old versions of all updated components, but still had the same problem

Using an old program

I decided to go back to the drawing board and start with the old version of the application and gradually add new features to a small part at a time.

• The old version was compiled using old components - the program works fine
• Updated to new DevExpress components - the program works great
• Updated to new ESBPCS components - the program works great
• Updated to new DeepSoftware components - the program works great

So now we know that nothing happens with updated sets of components ...

• Added 1 image to each of 2 image lists - the program works great
• Added a new database table - the program works fine
• Added code to open and close a new table - the program works fine
• A new action list has been added to the action and a menu item and a toolbar button have been added to the new action (the action is currently doing nothing) - the program works fine
• A new BLANK form for the application has been added and a code has been added to open a new form - BAM !!!

So, adding just one form to the application is what causes the problem! I deleted all the code to open the form, commented out the usage suggestions and deleted the usage record from the project source, and everything returned to normal.

Anyone got any 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 initialization section of the main form to create the splash:

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

---

Edit 3:

Anybody ??? You are welcome?

Answer 1

It may happen that the program waits for timeouts when trying to access resources that are not available on this computer, such as network drives or Internet hosts.

Try starting Process Monitor when starting your program and looking for open calls. Filter the output so that it displays only your process.

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

Answer 2

At first, performance issues can seem very complicated.

I have been to many teams where people tried to guess because of performance problems. This sometimes works, but much less efficiently than actually measuring the code.

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

There was a previous question that asked about Delphi Profiling Tools in which there are several possible tools that you could use.

If you cannot reproduce the problem on your development machine, it becomes a little more difficult, but not impossible. As a rule, I found that the problems are related to the application dependency, which is different and does not work well. Understanding the external influences on your application can help identify the problem.

Specific common problems in some of my applications.

• Network
• Database
• Application servers
• Installation or location of the data file (i.e. disk performance)
• Virus and malware scanners
• Another application is interacting with yours, such as a virus.

Monitoring network-related objects (i.e. databases, web services, etc.) I usually use Wireshark , which allows me to see if resources are responding at the expected time. My most common problem is poor DNS performance and can be found using Wireshark.

You can use the AutoRuns program to determine everything that starts when your computer is running, it is useful to determine the differences between the machines.

But most of all, I have a log that can be enabled in my applications, and this allows me to isolate the problem to a specific area of ​​the code. This reduction to a specific section of code reduces guesswork and allows you to focus on several possible problems.

Answer 3

I created a log function for this, which I call in certain places (in your case, especially during startup). It adds a time stamp for each text in the journal and saves them in TMemo, which is saved regularly. Not only very helpful when debugging, but can also shed light on your problem.

Answer 4

Do you use code signing - i.e. Microsoft Authenticode? If so, then outdated certification authorities on computers can cause significant delays at startup.

Answer 5

First, I would try to defragment the hard drive. If still slow, I would check the power source. Your hard drive may not receive enough power.

Answer 6

Idea 1:

One of the reasons I saw the application loading very slow was when you type or report system components, such as Developer Express Express Print, in your application.

The problem that occurs when using Developer Express Printing components is that I had a standalone or non-responsive network printer in my list of printers (check the icon on the control panel) that did not respond. Some of these Developer Express components seem to be reading some information from each printer that you installed, and the solution was to go to these clients and remove old printers from the control panel that are no longer in use. Each non-responsive network printer added up to 60 seconds for a TCP timeout by the time my application started.

Update - Idea 2:

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

Now, when you run this inside the Delphi Ide, you will see the messages and see how far they go into each other, and understand what is required for initialization. Instead of installing delphi ide on a machine that is running slowly, Debug View (which is less than one 400kb of one executable file) will be launched and it will show you these debug messages along with a nice time display (##. # Seconds) for each message .

View MS Debug here.

Answer 7

• Check if the same antivirus software exists on these 2 problem computers. If so, then your Delphi application may follow the byte pattern used in some viruses made in Delphi. Update virus definitions to solve the problem, or report a false positive to the antivirus company or change the antivirus software.
• Check if any printer is installed on these 2 problem computers. If so, add a printer and try again.

Answer 8

Do you allow forms to be created during initialization in the DPR source? If this is the case, you might be wondering if you want these forms to absorb memory all the time, moreover, if you want these forms to lose application time on loading.

Rule of thumb: if the form is used by LOT during application execution, allow it to be created when the application loads (this will work faster than when creating an instance "on demand"). If the form is not used very often at all (for example, a dialog box or a window), delete the line "Application.CreateForm" from the DPR source and instead create your own instance upon request ...

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

Now this form (which may not even appear during program execution) does not absorb system resources and will not slow down the application loading time.

This may not solve your problem 100%, but it will certainly help!