My project is very large and has a huge number of test steps. As a result, when I am writing 'feature' files I find my computer grinds to a halt. On very large feature files, even without typing anything, one of my CPU cores will max out, and performance will degrade to the point where typing is extremely laggy, forcing me to restart Visual Studio.
Even on smaller feature files, the performance when writing feature files is also extremely slow as the Specflow intellisense looks at all the test steps in the project.
Is there a way to disable the Specflow intellisense or even to stop Specflow from analysing step bindings? Is there anything at all I can do to improve performance here?
You can disable intellisense by going to Tools -> Options -> SpecFlow -> Editor settings -> Enable Intellisense.
But I am afraid that it will just stop showing that in IDE, but analysis continue, so it won't solve your CPU issue (according to the code)
But the option "Enable project-wide analysis" set to False should solve your problem
Related
Having just switched to VS2019 I’m exploring whether to use code analysis. In the project properties, “code analysis” tab, there are numerous built-in Microsoft rule sets, and I can see the editor squiggles when my code violates one of these rules. I can customise these rule sets and “save as” to create my own.
I have also seen code analyser NuGet packages such as “Roslynator” and “StyleCop.Analyzers”. What’s the difference between these and the built-in MS rules? Is it really just down to more comprehensive sets of rules/more choice?
If I wanted to stick with the built-in MS rules, are there any limitations? E.g. will they still get run and be reported on during a TFS/Azure DevOps build?
What's the difference between legacy FxCop and FxCop analyzers?
Legacy FxCop runs post-build analysis on a compiled assembly. It runs as a separate executable called FxCopCmd.exe. FxCopCmd.exe loads the compiled assembly, runs code analysis, and then reports the results (or diagnostics).
FxCop analyzers are based on the .NET Compiler Platform ("Roslyn"). You install them as a NuGet package that's referenced by the project or solution. FxCop analyzers run source-code based analysis during compiler execution. FxCop analyzers are hosted within the compiler process, either csc.exe or vbc.exe, and run analysis when the project is built. Analyzer results are reported along with compiler results.
Note
You can also install FxCop analyzers as a Visual Studio extension. In this case, the analyzers execute as you type in the code editor, but they don't execute at build time. If you want to run FxCop analyzers as part of continuous integration (CI), install them as a NuGet package instead.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2019
So, the built-in legacy FxCop and NuGet analyzers only run at build time while the extension analyzers can run at the same time the JIT compiler does as you type. Also, you have to specifically say to run legacy code analysis on build, whereas the NuGet analyzers will run on build just because they are installed. And analyzers installed as NuGet or extensions won't run when you go to the menu option "Run Code Analysis".
At least, that's what I get out of that page.
There's a link near the bottom of that page that takes you to what code analysis rules have moved over to the new analyzers, including rules that are now deprecated.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-rule-port-status?view=vs-2019
The different analyzers attempt to cover different coding styles and things Microsoft didn't cover when they built FxCop. With the little research I just did on this, there's a whole rabbit hole to follow, Alice, that would take more time than I have right now to devote to it. And it seems to be filled with lots of arcane knowledge and OCD style code nitpicks that make Wonderland seem normal. But that's just my opinion.
There's lots of personal and professional opinion about various rules in these and basic Microsoft rules, so there's plenty of room to use what you want and disable what you don't. For a beginner, I'd suggest turning on only a few rules at a time. That way you aren't inundated with more warnings and errors than lines of code you might have. Ok, so that might be a bit of an exaggeration, but there's so many rules that really are nitpicks, especially on legacy code, that they aren't really worth it to have enabled, since you likely won't have time to fix it all. You will also want to do basic research and use "common sense" when you decide what to enable. ("Do I really need to worry about variable capitalization coding style consistency on an app that's been ported into 4 different languages over 15+ years and has 10k files?") This is both personal and professional opinion here, so follow it or not.
And don't forget the rules that contradict each other. Those are fun to deal with.......
It seems like over time Embarcadero RAD Studio (I use XE4 Starter for programming Delphi) has gotten more and more sluggish. I know with other IDE's I've used sometimes you end up with bloat and detritus of temp files and cache files and other unneeded things the IDE generates, and periodically it can help to manually go in and clean those things up.
Are there any particular file removal, or other IDE maintenance a programmer should do periodically to keep RAD Studio running smoothly at peak efficiency?
There are really many angles to how the IDE performance is affected. And there's essentially two levels to look at it on: What's installed in the IDE, and what's required by your immediate project.
IDE Maintenance
There's not necessarily anything you should have to do on a regular basis to your IDE. However, you should make sure that your library path is up-to-date. This is one of the most common things I ever need to manage in the IDE.
Then there's the third-party libraries, components, add-ons and fix-packs that you can install onto the IDE. Each one of these has the possibility of slowing things down, so make sure you only have things installed that you actually use.
Project Maintenance
Performance of the IDE isn't usually hindered by maintenance of a project. However, a very large complex project (or project group) may wind up slowing it down. Cleaning of the DCU files of a project shouldn't be necessary on any regular basis, but can often help clean up and forcefully re-compile anything which the IDE may have neglected to keep up to date. I've seen issues which were solved by deleting DCU files and recompiling them. Remember, DCU files are essentially compiled code, and is mostly for the purpose of caching the compilation so that it only needs to compile those units which have changed since the last compilation. So, cleaning up the DCU's will result in the next compilation taking a little longer than usual. Still, not much worth the pain.
Conclusion
There's a batch file I use commonly to clean up unnecessary files in different project folders. That batch file is scripted like below, and simply deletes any temporary files I don't need to keep around. But it's only needed on rare occasions when I'm cleaning up the source, and not really on any schedule.
del *.dcu
del *.dof
del *.dsk
del *.identcache
del *.local
del *.~*
del *.cfg
del *.dsm
del *.rsm
del *.otares
Note that the same or similar can be accomplished by choosing the "Clean" option in the IDE for any given open project.
Edit
You can also accomplish best IDE performance by keeping track of how your project interacts with the IDE. For example, components or controls which perform heavy actions (such as database connections with data aware controls).
OP hasn't characterized the nature of HOW the IDE "has gotten more and more sluggish," so anything anybody says here is little more than random speculation.
First off, I've never used the Starter Edition of Delphi. Aside from that, I've never noticed any particular slow-down on different versions, other than what you'd expect from normal stuff. That is, if you load bigger files, it can take longer to do stuff in the IDE. More installed libs and components take longer to load at startup, but impose negligible impact inside the designer. Deleting files like those above can slow down builds because the compiler needs to reproduce them; but if you're not using that project, then there shouldn't be any impact whether they're present or not. And poorly designed components can take a toll on IDE performance.
It's entirely possible there may be some optimizations turned off in the Starter Edition, or things missing that might result in performance hits over time. It's not as "feature complete" as the full IDE, although I've never investigated the differences. I just stick to full released products because I use them for production work.
Also, maybe it's time you upgraded your computer. You could be dealing with limitations in virtual and physical memory that have nothing to do with Delphi, which is a rather large app in its own right. I run Delphi inside of a VMWare VM on a MacBook Pro, and it works fine unless the memory gets tight, then it can slow way down. (Again, without more specifics, it could really be tons of different things.)
I have a solution which contains 11 projects. The main project is ASP.NET MVC. When I run the project in debug mode (F5), the main page of the site loaded approximately 2 minutes. Note! Home page of the site is a login form, there's not a lot of sql queries.
Interestingly, when I run the project in without debug mode (ctrl + f5), the main page of the site loaded in a few seconds.
I tried to look for solutions. For example, I found this solution. Unfortunately, I was unable to execute the instructions written by Zeb Kimmel.
I would be glad to any advice and suggestions.
P.S. I have a processor intel core 2 duo e6300, 3gb ram, windows 7 (32 bit).
Visual Studio IDE settings
Go to Tools - Options and set the following:
Projects and Solutions - Build and Run. Check "Only build startup
projects and dependencies on Run"
This will prevent it building all the projects all the time!
Environment – General
Uncheck "Automatically adjust visual experience based on client
performance"
Uncheck "Enable rich client visual experience"
Uncheck "Use hardware graphics acceleration if available"
IntelliTrace – General
Uncheck "Enable IntelliTrace”
This disables a specific tracing technology most people don't use, that adds major overhead.
Environment - Startup
Set "At Startup" to "Show empty environment"
Disable "Download content every..."
PC setup
Get an SSD! We use an Intel SSD caching system, which is improves
our build times by about 50%. Specifically it's motherboards with
20GB mATA SSD drives, using Intel Smart Response Technology (or is
it called Rapid Storage Technology collectively?). We have it set to
"maximized" mode, which means it caches writes as well as reads. I
suspect, but haven't yet tried, that a pure SSD would improve it
even more.
If you can't get an SSD, defragment drives properly. The built-in XP
one might not good enough to defragment free space if the drive has
become heavily fragmented at some point! I used: Auslogics Disk
Defrag.
Exclude virus scan on network, work and VS folders.
Project specific
Unload projects if you're not maintaining them or are unlikely to
affect them in your work.
Refer this links
Ways to speedup Visual Studio 2010
http://social.msdn.microsoft.com/Forums/vstudio/en-US/09893b7e-8882-49e6-a1df-4b1e0ce82843/tips-for-speeding-up-debugging-stepping-through-code
I have a project in Delphi7. Its is rather large consisting of 40 odd forms and frames.
Recently, the compiler only allows me to compile the project once so i can run it, then every re-compile the IDE hangs and i have to end the Delphi process. Before this occurs, my CPU goes to 50% (on dual core machine) so my deduction is the compilation process has gone into an infinite loop. The Executable it produces is not runnable and usually at a fixed size after it hangs.
I was wondering how i can go about finding where this inconsistency in my project is. Other projects do not suffer from this same issue.
You can use Process Explorer to discover what compiler is doing (reading a file, or ...).
Check the QC 3807 issue.
Check the system resources - free disk space, memory. Clean the temp folder. Check the disk for errors. Do you have antivirus running ? If yes, then try to turn it off.
Use "process of elimination", to see if it's something in your code.
First, make a backup of where you are, or save to your CVS (you ARE using version control, right? RIGHT? good.) Revert your branch to an earlier version where it worked. See if that works. If so, merge half of the changes from the present-day version. If that works, try the other half. Keep cutting things in half, and you'll find the code that causes the problem, by process of elimination.
Or, it may turn out to be something in the configuration. Carbonite may be your friend here.
You can either:
Enable "Compilation progress display" in the "Environment Options" window, in the "Preferences" tab.
Use the command line compiler bcc32.exe to have a detailed console output.
Both will let you know which file is hanging the compiler.
Take a look at the great Delphi Speed Up tool, which allows e.g. to abort CodeCompletion and HelpInsight by ESC/mouse move.
I'm doing quite a bit of NAnt script writing at the moment and would love to know how I can speed the process up?
I'm currently editing the script in Visual Studio, then going to the command line to test the output. I like how Visual Studio can be configured to autocomplete your NAnt commands (via xsd) but I'm still testing my scripts on the command line.
Are there any tools that bring all of that together? I use Notepad++ quite a bit but would switch allegiance to another editor that has editing and command line functionality built in.
I guess what I'm looking for is something like NAnt Builder (http://www.nantbuilder.com) but I don't really want to spend that sort of money when I have my free current alternative.
If you use ReSharper, it will handle this for you. And when you look at the overall value that the tool provides (almost any "favorite VS add-in" question on here lists ReSharper at the top), it is a pretty easy decision to go for it. This link provides a list of features.
A free alternative that requires some customization is Notepad++.