In VS Code, when I run a Julia file, if I have included the library ProfileView via using ProfileView, I get the following warning.
Warning: You are using Gtk on Windows which is currently not recommended. Your REPL/IDE and anything depending on task switches will become sluggish and much slower (up to ~85x slower).
The IDE does become very sluggish.
What should I do to fix this? JuliaPro and Atom are also very slow, and this slowness was why I switched to VS Code (the reason for the slowness may have been different, but I mention this just in case it is useful).
As suggested by the error message, I'm on Windows 10.
per the warning message you are getting, the only way to "fix" this would be to not use a Windows computer. There's nothing you can do about the slow down on Windows with respect to GTK.jl at this time.
I am running a selenium project that crawls through websites. The project opens links in new pages and checks for content, then closes the opened window. I have noticed that after about 5 minutes of opening windows the ram runs about 3gb out of 4gb for firefox in the task manager. There are other programs running as well, so everything gets slow and starts stalling. I am curious as to why firefox's ram does not reduce after closing the window, but continues to climb. I have tried using firefox cache preferences and sessionstore preferences, but nothing has helped. Has anyone encountered a similar problem or know anything about this? Running selenium 2.53 on firefox 41.
This is the best solution. Without knowing your exact setup I'm going to explain what fixed the memory leak for me.
I'm running a few extensions in Firefox, Adblock Plus, Auto Refresh, and others. I disabled my extensions to see if that fixed the problem, it did!
Keeping a couple on at once I narrowed it down to Adblock Plus, and found that other people have had memory leaks with it as well, so I switched it out for uBlock Origin. I hope this helps.
I'm using Visual Studio 2012 Update 3. When I open a project, VS automatically creates a process called <myproject>.vshost.exe, even before starting to debug.
When I start debugging and later close the debug application, most of the times the <myproject>.vshost.exe process closes as well. When this happens, devenv.exe starts taking up 3x more memory than normal and CPU goes up to 25% (on a i7 Quadcore with 8GB ram) for around 1 minute. At the end of 1 minute, a new <myproject>.vshost.exe opens up (even though I'm not debugging), CPU falls back down to 0 and memory drops back down as well.
Trying to start debugging whilst the CPU is at 25% and <myproject>.vshost.exe is not running in the background will results in the solution building but the debug does not start.
If I wait until the CPU falls back down and <myproject>.vshost.exe process is running again then I can start debugging normally.
This happens to me 80% of the times after closing the application I am debugging. The remaining 20% of the times when I stop debugging <myproject>.vshost.exe continues running in the background and I am able to start debugging again immediately after with no delay.
This also happens regardless of code changes in between debugs.
This is a new install of VS2012 U3, I've tried resetting all settings and disabled ReSharper but still no joy.
I don't want to disable vshost debugging because of the features I would lose.
Has anyone else encountered this problem before? Is this a known issue? Are there any solutions/workarounds?
EDIT
I changed the platform from Any CPU to x86 and it appears to work properly, but I still can't understand why I shouldn't be able to debug it as Any CPU. Even though this might be the workaround I'd still be interested in knowing whether this is a known issue and if there are other (better) solutions.
By 'working properly', I mean that when I stop debugging the vshost doesn't close, in fact it never closes, but the CPU of devenv stays at 0% and it allows me to start and stop debugging as many times as I want one right after the other.
EDIT2
Actually it appears that changing the platform to x86 only worked properly for a while, after about 20 rebuilds it is now doing the same as leaving it as Any CPU.
On another note, closing and opening VS makes no difference.
I've ended up formatting the computer again and re-installing everything from scratch. For not it appears to be working fine, let's see how long this lasts for.
I know this is several months old but I'm trying to post this answer in a few places since this is what was causing my ills: I had the Data Sources toolbox open in Visual Studio 2012. Once I closed that, it seemed to eliminate the lengthy delays when switching windows. You may also want to close Server Manager if you don't need it open.
I know this is old Post but, I think I need to share my solution for everyone.
and this is my first post so, please improve the answer if I miss something.
I have the same issue with Visual Studio 2012, When I try to build or debug it will use CPU up to 100%.
So, I try below steps to reduce the CPU usage while debugging:
Please close unnecessary opened file.
Hide unnecessary debugging panels like: breakpoints, auto, local, output, find symbol result, etc.
If still use high CPU then try to hide call stack panel.
Remove unnecessary breakpoints.
I have a complex C# project that I ported over from C++ and now I'm in the middle of debugging. Things are working great most of the time but more often than not I have huge problems with Visual Studio and debugger attached to WP7 emulator. For some strange reasons, my debug session is often abruptly terminated while stepping through the code without any indication from VS or any trace left in the Output window.
There are even some cases when a breakpoint is hit and then when I hover over a particular variable, VS simply exits the current debugging session. If I refrain from inspecting the variable contents, nothing happens and VS waits happily forever.
As the app is a memory hog by definition, I am wondering whether I am hitting any debugger / WP7 / emulator limits of any kind. Why would a mouse over variable terminate debugging session? Most of all, why is there no trace of what happened? I am left to wonder whether this is a VS issue or an emulator issue or even an app issue.
What are your computer specs?
I have seen similar problems on computers with low specs, especially computers with low memory.
Try clearing out memory hogs from your PC (CCleaner is a good tool) and running Visual Studio in administrator mode.
I have found this post which has helped me immensely. It appears that having ToString() overrides can sometimes crash the debugging session. I have implemented mine for the sole purpose of having customized value representation of variables/values in the debugger.
After removing all the ToString() overrides I am able to debug normally again. The thing that still puzzles me is the fact that no exceptions are leaked from my ToString() overrides so I wonder why debugger behaves the way it does but at least the problem is solved for now.
I hope this helps someone.
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!