Fresh installation - plugins disabled, no malware. Chromium runs without delays. Firefox on every other action, including typing every now and then - takes 3-5 second pauses, sometimes displays a running wheel when the delay is even longer.
Started at certain point in time. De-installation/re-installation didn't cure. Running as a single process didn't cure. Latest version.
Any ideas what can be causing this, specifically for the Firefox?
Upgrade to v67 - I remember reading some glitch has been removed in prior versions that might have been causing this behavior.
Also, another idea would be not to limit your cache to a very low space.
+1 to move this question to SuperUser.
We are noticing a strong downfall in ODOO performance of the users that use ChromeOS, either using ChromeBook or ChromeBoxes (with different configurations...also very fast ones). After the startup of the machine all seems fine but after a while (depending on your activity) we notice a strong downfall in Performance. It is like the machine is not responding at all and after a few seconds (sometimes up to 30 seconds) it continues with opening the screen and seems to be very quick again. Restarting the browser and clearing the cache gives some relieve but the issue keeps coming back. Strange thing is that on our older windows machines (running Chrome Browser) we do not see this issue.
I use PHPStorm 5.0.2 for debugging php/mysql projects with WAMP framework (php 5.3.1, Apache 2.2.9, mysql 5.5.24 on Windows 7 platform).
Question 1: Some times in a project, when watch debug variables are used, they take some seconds to refresh on the debug panel, after each code step. Each watch variable takes a few seconds to refresh, so the more watches have been defined, the more slowing down takes place during code stepping, rendering debugging disappointedly slow. So, for example, I cannot press 'Step over' every second, because I have to wait till watch values are refreshed, before I press the next 'Step over' and this may take 5 or more seconds.
This didn't use to happen before, it started happening lately and also it doesn't happen all the time. When it doesn't happen, the code stepping can advance very quickly, as it usually did.
In this project I have set up quite a few breakpoints, so I was wondering if they are the culprit. I tried to disable most of them (not delete them, since I need to keep them for future use), but I didn't see any improvement.
I also tried different xdebug versions, but no change took place.
I have also tried to switch browsers, delete browser data (cache, etc), restart WAMP server, browser, phpStorm, even Windows, but many times the issue remains. Other times, it disappears for a little while and it reappears later in the code.
I was wondering what reasons might produce this slow refresh.
Question 2: Is there any way to export or save breakpoints from a project?
Question 3: If I tried PHPStorm 7, in case this slow-refresh issue disappeared, could I open the PHPStorm 5 project in order to not loose the breakpoints I have already set?
I'm currently learning OpenGL and I've noticed a rarely occuring performance problem:
My program is rather small so it's not a performance problem with the code itself, but when I'm running the code via Visual Studio I sometimes only get 1-2 FPS instead of the usual 60.
Once this happens I can restart the program as often as I want to (in debug and release mode alike) and it won't go away.
However, when I close my Firefox (or manually shut down the plugin-container.exe though task manager) and restart my program everything is fine again. After that I can start Firefox again (with the same tabs open) and the bug does not reappear.
I use the newest version of Firefox, and I've had this bug with several programs already - both made by me and others and using different versions of OpenGL. However I don't think I've had this problem when starting a compiled exe directly, but only by using the Run feature of Visual Studio.
I've searched the web but I only found a link about the generally bad performance of this plugin-container.
Does anyone else have this problem? Do you know any walkarounds or fixes?
PS: Regarding isti_spl's answer:
The CPU utilisation of the plugin-container.exe jumps to the 50% limit when the problem happens.
I'm working with Visual Studio, but the problem only occurs when I also have Firefox running (it most certainly is because of this plugin-container, so it probably won't happen with other browsers).
It's hard to isolate the problem because I can't replicate it. It might happen 1 out of 50 times.
I'll see if closing flash-related tabs (youtube, blip.tv etc) fixes the problem next time it happens.
Can you isolate the problem?
You first mentioned running visual studio then firefox. Please try to run separately.
Under FF. is it caused by WebGL or flash plugin? Is it caused by visiting specific sites?
Is it FF specific or happens under other browsers too?
Does CPU utilisation jump high? Please verify that too and which process consumes most CPU.
Not sure, but likely gpu driver + flash problems.
If so, the problem is not in your code, other GL program should be affected too.
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.
Recompiled the old version using the old components - program works fine
Updated to new DevExpress components - program works fine
Updated to new ESBPCS components - program works fine
Updated to new DeepSoftware components - program works fine
Ok, so now we know there is nothing with the component sets I've updated...
Added 1 image to each of 2 image lists - program works fine
Added new database table - program works fine
Added code to open and close the new table - program works fine
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
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?
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
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.
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.
Are you using code signing - ie Microsoft Authenticode? If so, then outdated certificate authorities on the computers can cause significant delays to startup.
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.
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.
Check if there isn't any printer installed on those 2 problematic computers. If it is so, then add any printer and try again.
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.
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!