Speeding up VS2010 when working with WF4 IDE - visual-studio-2010

I am developing on our development server. Windows Server 2008 R2 64 bit OS, 256GB of RAM, 16 CPU machine. VS2010 with SP1 installed.
I have a huge workflow (around 30K lines in the XAMLX file). Every time I make even a small change in an activity, like changing the display name, it takes about 2-3 minutes to register the change. VS2010 is unresponsive all this time. It is extremely frustrating.
What is causing this and how can I make it run faster? Is there any setting in VS2010 that will make this run faster?
Thanks!

The most likely cause of the delay is the associated work flow designer trying to update to the change you just made. It's doing so synchronously on the UI thread and hence you see the delay.
The only way I can think of to stop this is to not open the designer. Instead just open the raw XML file and edit it directly. To do this
Close the file
Right click on the file in solution explorer and select "Open With"
Choose the XML editor
Also I encourage you to file a bug on connect about this behavior.
http://connect.microsoft.com/visualstudio

Related

RAD studio takes very long time to open

I was using RAD 10.1 (Berlin) with no problem until now... Last month I applied Windows Creator Update and was occupied by other businesses... Now, each time I start the IDE, the loading progresses quickly up to "All design time packages loaded". At this time RAD studio sits on its splash window and consumes ~25% CPU. It takes at least 10 minutes before the IDE appears...
I've installed RAD 10.2 (Tokyo) and all provided patches, hoping for a fix... But the problem remains the same.
I can't go back to previous version of Windows 10 (more than 10 days after install).
I've already searched for an answer and Matthias E suggested that it was linked to https://quality.embarcadero.com/browse/RSP-17972.
But, in my case, the (very) long period stands only for IDE loading even when there is no project to (auto)load. I'm not talking about the time-period to load the project or to start project execution or even to start the application execution. Once the IDE has been loaded (after ~20'), everything (editing, compilation, building, debugging, execution) is working quickly...
I have become accustomed to never close the IDE once opened but this is particularly disturbing.
Could you help me ?
--- Edited ---
For those who cannot access the link above, here is the content :
Details
Type: Bug Bug
Status: Open Open
Priority: Major Major
Resolution: Unresolved
Affects Version/s: 10.2 Tokyo, 10.1 Berlin Update 2
Fix Version/s: None
Component/s: Debugger, IDE (Development Environment), Libraries/Frameworks
Labels: None
Platform: Windows 10
Language Version: English
Edition: Professional
InternalID: RS-83785
InternalStatus: Open
Description
The debugger goes haywire for everyone in our organization with Creators and Tokyo/Berlin. Reverting to Windows Anniversary brings back the sanity.
Debugger problems with Tokyo/Berlin and Creators:
App takes a long time to load with modules loading and unloading and re-loading many times
IDE freezes
Memory consumption of bds.exe explodes, sometimes (> 3GB)
I will attached before and after screenshots showing how modules load and unload and re-load with Windows 10 Creators.
I presume these problems have the same root cause(s) than those in https://forums.embarcadero.com/thread.jspa?messageID=884382*
--- ---
Thanks to Lieven Keersmaekers's suggestion to use procmon, I was able to find the cause of the problem. RAD studio was heavily trying to access an enormous (128 GB) zip backup file (see : qed-electronic.com/Download/170808-ProcMonTrace.jpg ). I've simply moved the backup file to another location and RAD studio now starts as before. I have no idea why RAD wanted so much to access this file : none of my project files were located in this zip. The Windows Creator Update was apparently not guilty...
bds.exe must be launch with only one CPU !
CPU Affinity CPU=0
Thx to Javorszky
https://community.embarcadero.com/forum/installation-issues/1408-running-from-ide-freezes-windows-10#4173
To run quickly without entring TaskManager and change Setting CPUAffinity,
just create a batch file on the desktop:
cd "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\"
start /affinity 1 bds.exe
Why ?
"The reason for this is that most applications you run these days have been designed with multi-core processors in mind and will work with the operating system to distribute their operations as evenly as possible across all the available cores. "
see : https://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/

Any change to XAML or .proj makes VisualStudio 2013 take really long time to save and in not responding status

Problem description: whenever I make any change to XAML file and save it, it takes at least half minute during which Visual Studio 2013 is totally not responding. Same thing happens when I try to load a .proj file, open or loand a solution (I understand it takes time to load a solution/project, but it takes longer than I experienced before). However, when I try to save a normal class file, it doesn't behave like that.
This problem has been existing for a while. My colleague told me it might be because I installed some unnecessary SW but it looks like I don't have those many extra SW anyway. Also when I check the task manager, I noticed that when this not-responding thing happens, the "Antimalware Service Executable" suddenly takes much system resource, more than 10% of the CPU. This I don't really understand. Why on earth the anti-malware service is suddenly running when saving the XAML/clearing the solution?
I searched many posts tried some solutions. For example, I tried to open XAML file using XML editor, which doesn't show the designer (I suspected too that I had something to do with rendering my XAML) but it didn't help.
Then I found this post. In the "workarounds" section there is the solution works for me: exclude visual studio 2013 (devenv.exe) process from windows defender (the Antimalware Service Executable process) so it won't scan it when VS is apparently making a fuss so windows defender felt necessary to monitor that. This feels weird and I don't know what windows defender did (especially that I only tried to save a XAML file which essentially is a modification to one text file anyway).

why is vs2010 so slow lately? Its nearly unusable

Not sure what has happened on my dev machine but I can barely use visual studio 2010 these days. I have a copy of professional edition installed on a win7 pro x64 build running on top of a i5 M430 and 6 gigs of ram.
With only VS2010 open i've seen the process leak away to 600,000k+.
The editor is extremely slow. Every character I type sends the gui into "Not Responding" for 5 seconds and starting/stopping the debugger is a ~30 second operation.
I've done a repair install. No change.
I've removed productivity power tools and installed the perfwatson extension.
When I installed perfwatson the GUI sped up a bit while opening/loading a project. But the text editor still has an awful delay.
What else can I do? Harware rendering is off in my environment options.
an example of the slowness (literally): typing Height="1024" takes about 30 seconds to display in the text editor and do its update flash to go out of not responding. The word "Height=" takes 5 seconds to show. The intellesense and blank " " takes another 5 seconds. Each digit pops in every five seconds after that.
Needless to say even trying to edit existing work is a frustrating experience.
edit: rolled back one version on video driver. No noticeable changes after reboot.
edit: did some winforms projects today. No slow issues with this project type. Must be something with just wpf/sl projects.
edit 8/18/11: Took troublesome project to the production server. VS2010 editor works great there. Very snappy and responsive. Not at all slow. So it's not something inside my project. It's something in my machine. But a full out OS rebuild is something I can't just do now. Probably will start a bounty soon.
Delete the .sdf and .sou that have the same base file name as your solution file.
If your solution file is
c:\MyProject\project.sln
You should delete
c:\MyProject\project.sdf
c:\MyProject\project.sou
This solves 98% of the problems of slow VS.
These files contain intermediate information that is not important for the functionality of the solution and as time goes by they swell up and become bloated and fragmented. VS relies on these files for and if dealing with them is slow, everything is slow.
I know this is an old post but I have just had an issue where my visual studio project has been working fine for about 2 1/2 years and suddenly every time I clicked run I had to wait about 3 minutes and the same when clicking stop. I tried the old windows reboot but to no avail.
I found a post about deleting the projects .suo file (it was only 4MB).
I deleted the .suo file and everything is completely back to normal. I guess the file had corrupted or something.
Having a large number of breakpoints or a large number of files open can cause serious performance problems, but it sounds like your problems are worse than that...
A bios update and a intel chipset update on my machine solved nearly all my performance issues.
The slowness started to creep out into the OS and I was pegging the cpu at idle. I've got 4 cores and 8gb ram. It shouldn't do that. Now its happy at 8% load at idle.
Thanks to those that tried to help.
had the same problem. not sure what causes this ridiculous performance nightmare, but eventually i had to re-install windows. This same issue was posted on Microsoft forums but the best answer was to re-install VS or windows.

Program runs slow on just a couple of computers

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!

Visual Studio 2005 Memory Usage

I find that quite often Visual Studio memory usage will average ~150-300 MB of RAM.
As a developer who very often needs to run with multiple instances of Visual Studio open, are there any performance tricks to optimize the amount of memory that VS uses?
I am running VS 2005 with one add-in (TFS)
From this blog post:
[...]
These changes are all available from the Options dialog (Tools –> Options):
Environment
General:
Disable “Animate environment tools”
Documents:
Disable “Detect when file is changed outside the environment”
Keyboard:
Remove the F1 key from the Help.F1Help command
Help\Online:
Set “When loading Help content” to “Try local first, then online” or “Try local only, not online”
Startup:
Change the “At startup” option to “Show empty environment”
Projects and Solutions
General:
Disable “Track Active Item in Solution Explorer”
Text Editor
General (for each language you want):
Disable “Navigation bar” (this is the toolbar that shows the objects and procedures drop down lists allowing you to choose a particular object in your code.
Disable “Track changes”
Windows Forms Designer
General:
Set “AutotoolboxPopulate” to false.
Set “EnableRefactoringOnRename” to false.
Upgrade to a 64-bit OS. My instances of VS were taking ~700MB each (very large solutions).. and you rapidly run out of room with that.
Everyone on my team that has switched to 64-bit (and 8GB RAM) has wondered why they didn't do it sooner.
minimize and re-maximize the main vs window to get vs to release the memory.
By uninstalling (and re-installing) Visual Assist the problem got solved for me.
The number 1 thing you can do is switch to Windows 8.
It uses memory sharing / combining if the same DLL or memory page is loaded into multiple processes. Obviously there's a lot of overlap when running two instances of VS.
As you can see I've got 4 Visual studios running and the shared memory column (you need to enable this column for it to be visible) shows how much memory is being shared.
So in Windows 7 this would use 2454MB but I'm saving 600+MB that are shared with the other devenv processes.
Chrome too has a lot of savings (because each browser tab is a new process). So overall I've still got 2GB free where I'd normally be maxed out.

Resources