Support for raw memory dumps was probably the most voted and long-awaited dotMemory feature. Finally, it’s available in dotMemory 2017.2!
Indeed, there are cases when it’s impossible to profile a problematic application locally or remotely and take a regular dotMemory snapshot for analysis (e.g., because of security policies). Your last resort in such a case is typically a raw Windows memory dump. It can be taken with a number of tools, with the two most popular being Task Manager (comes with the operating system) and Process Explorer. Now, all you have to do is simply copy the dump to your computer and open it in dotMemory using the Import Dump command.
Image may be NSFW. Clik here to view.
That’s it! The dump is converted to an ordinary dotMemory snapshot, so you can analyze it using all of the sophisticated dotMemory features like automatic inspections, retention path diagrams, etc.
Important notes
The feature is currently in Beta status. While it’s 100% functional, the number of possible combinations of Windows and .NET Framework versions is really huge! This means it’s possible that for some combinations, dotMemory won’t show you all of the expected data in the resulting snapshot. Please send us your process dumps should you face this issue!
When creating a dump of a 32-bit application with Task Manager, make sure you use a 32-bit version of the tool. You can find it in C:\Windows\SysWOW64\taskmgr.exe.
We have tons of ideas on how to improve the feature (dumps contain much more data that we’re currently able to analyze), so this is still work in progress.
If you feel like trying importing dumps right now, download and install ReSharper Ultimate. Please ask your questions by posting comments to this post.
Apart from 300+ fixed issues, ReSharper 2017.3 includes both long-awaited and unexpected features that will hopefully help you in your day-by-day routine:
Visual Studio debugger extensions, such as searchable DataTips, values displayed right in the text editor, navigation to breakpoints, and creating breakpoints from the Find Results tool window.
Performance guide for fine-tuning both ReSharper and Visual Studio settings to improve the overall IDE responsiveness in one place.
Major updates to code formatting engine: support for aligning code in columns and other new code styles, as well as a way to disable or enable formatting for selected blocks of code with comments, or for files with EditorConfig.
Improved Extract Method refactoring to support creating a local function and returning a value tuple instead of out parameter.
Links to external resources in to-do items.
New C# typing assists.
Find Usages/Call Tracking presentation update.
Enhanced Preview pane in tool windows.
Support for tuples and <inheritdoc/> in VB.NET.
Ctrl+Shift+Click action to show the result of ReSharper Go to Declaration in Visual Studio Peek preview overlay which now works in Visual Studio 2015 and 2017 in addition to 2013.
TypeScript support improvements, such as better performance when using type guards, auto-completion for imported paths, and tracking changes in npm modules.
New code generation action to create deconstructor from selected fields/properties for C# 7.
Other ReSharper Ultimate tools have been updated as well:
ReSharper C++ 2017.3 brings the same debugger features as the mainline ReSharper, improves language understanding including the C++17 and C++14 specification, integrates Clang-tidy, adds more code inspections, context actions, and formatting options, and supports Catch2 in its unit test runner.
dotTrace 2017.3 provides async/await and Tasks support in Timeline profiling mode, adds forecasting performance to Timeline Viewer, and introduces viewing backtraces in methods and subsystems.
dotCover 2017.3 supports Continuous Testing for .NET Core tests, improves ‘Show Covering Tests’ popup, introduces new document coverage summary indicator in ReSharper marker bar, and brings C# 7 local functions support.
dotPeek 2017.3 introduces “Tools | Show PDB Content…” menu action, and adds “Open from NuGet Packages Cache” dialog to Assembly Explorer tab.
dotMemory 2017.3 improves object search and receives a solid set of bug fixes.
When you explore a memory snapshot, it’s never easy to find the object you need. A typical application operates millions of objects, which means a memory profiler must offer adequate searching capabilities. Before dotMemory 2017.3, object set views provided only basic string search. Now, you can make your search more efficient by creating complex search patterns based on CamelHumps and special symbols.
Wildcard search
As usual, the asterisk (*) wildcard means literally “anything” and can be used in any part of your search pattern. For example, sys.*.data may return System.Windows.Controls.Datagrid, System.Data and System.Windows.Data.Binding.
If you want to search only among namespaces, you can do this by adding a period (.) at the end of the pattern. For example, sys.*.data. will return System.Windows.Data.Binding but not the System.Windows.Controls.Datagrid class: Image may be NSFW. Clik here to view.
Search for arrays
If you want to only see arrays in search results, simply use square brackets, []. To find arrays of a specific dimension, use commas inside: for example, str[,,] will return String[,,]. If you omit the closing bracket, search results will contain arrays with the specified dimension and all higher ones: str[,, may return String[,,] as well as String[,,,]: Image may be NSFW. Clik here to view.
The Instances view has a bonus: here you can search by array size or size range. Image may be NSFW. Clik here to view.
You can exclude arrays from search results by adding !a anywhere in the pattern.
Search for types with generic type arguments
To only search for types with generic type arguments, use angle brackets <>. Similar to array search, commas inside the brackets define the number of arguments. Image may be NSFW. Clik here to view.
If you add !g anywhere in the pattern, all generic type arguments will be excluded from the search scope.
Though dotMemory Unit is not part of the ReSharper Ultimate bundle, in this release dotMemory Unit 3.0 is provided with ReSharper 2017.3. What’s in this release?
.NET Core 2.0 support
You’ve asked us to add support for .NET Core for quite a while. Now, with the more mature and stable .NET Core 2.0 release, this request became even more urgent. So, yes, dotMemory Unit 3.0 provides support for .NET Core 2.0 unit tests (currently, only on Windows).
Getting groups of objects
Due to a separate release cycle, dotMemory Unit 2.4 was released in the interim between ReSharper Ultimate 2017.2 and 2017.3, so, probably most of you simply missed it (especially, taking into account that we didn’t make any special announcements). Let’s fill the gaps in this post.
The most significant feature in dotMemory Unit 2.4 is the GroupByType method that allows you to quickly group objects by type inside of an object set. The method returns a collection of TypeMemoryInfo instances, each representing a particular group and allowing you to get data on ObjectsCount, SizeInBytes, Type, and TypeFullyQualifiedName.
dotMemory.Check(memory =>
{
var group = memory.GroupByType();
var largeTypes = group.Where(typeMemoryInfo =>
typeMemoryInfo.SizeInBytes > 1000000).ToList();
// do sth. with largeTypes
});
The Traffic class also gets the similar GroupByType method. The only difference is that groups are presented via the TypeTrafficInfo type. Each group (an instance of TypeTrafficInfo) allows you to get info on allocated and collected objects (AllocatedMemoryInfo and CollectedMemoryInfo) and of course data on objects type (Type and TypeFullyQualifiedName):
var checkPoint1 = dotMemory.Check();
// do sth.
dotMemory.Check(memory =>
{
var traffic = memory.GetTrafficFrom(checkPoint1);
var group = traffic.GroupByType();
var heavyTrafficTypes =
group.Where(typeMemoryInfo => typeMemoryInfo.AllocatedMemoryInfo.SizeInBytes > 1000000).ToList();
// do sth. with heavyTrafficTypes
});
And finally, one last important note: Snapshots collected by dotMemory Unit 3.0 can be opened only in dotMemory 2017.3.
As usual, we suggest you check out all the latest features of dotMemory Unit for yourself. The easiest way to do this is to install the corresponding NuGet package into your project: Install-Package JetBrains.DotMemoryUnit
Baseline conditions: You have a server running a .NET web application. It appears the application has an issue: It doesn’t work as fast as expected, it consumes more and more memory over time, it has any other performance/memory issue of your choice, whatever. It doesn’t really matter what exact issue it has, the workflow is always the same:
Profile the app in order to get performance/memory data.
Analyse the data to determine the issue.
Though step 2 seems to be the most important here, communication with our users shows that you might easily get stuck in step 1. In most cases, installing a profiling tool like dotTrace or dotMemory to the server is not an option at all. Server environment may impose many restrictions: no GUI, security policies, etc. So, what options do you have? In this article, we’ll take a look at all possible ways of profiling a .NET application on a server using the dotTrace + dotMemory toolset.
Memory dumps contain less data than dotMemory snapshots
Remote profiling
Image may be NSFW. Clik here to view.
Remote profiling is the best choice when it comes to a sudden performance drop / memory issue.
How it works: dotTrace / dotMemory is running on your local machine, the remote agent is running on the server, both communicating via TCP, as easy as that. The best thing about remote profiling is that you still work with the easy to use dotTrace/dotMemory GUI and the collected snapshots are automatically copied to and opened in dotTrace/dotMemory.
So, that’s what you should do to make it work (the instructions are almost exactly the same for both dotTrace/dotMemory):
On the server, do the following:
Copy the RemoteAgent.zip archive from the dotTrace/dotMemory installation directory on your local computer, to any directory on the server. For your convenience linking to the archive is available right on the dotTrace/dotMemory remote profiling page: Image may be NSFW. Clik here to view.
Unpack the archive on the server.
Start RemoteAgent.exe from the console on the server.
Ensure that inbound connections to Remote Agent are not blocked by the firewall.
On the local computer, run dotTrace as a standalone application. The dotTrace Home window will open.
In the right panel, choose the Remote tab.
In the central panel, specify the address of the remote agent service in Remote Agent URL.
By default, the URL is net.tcp://[remote_computer_IP_address]:9100/RemoteAgent
Click Connect to establish connection with the remote host.
Image may be NSFW. Clik here to view.
Once you get a snapshot, it will be automatically uploaded and opened in the current dotTrace/dotMemory instance.
Profiling via console tools
Image may be NSFW. Clik here to view.
Console tools are the best if you need to automate profiling: e.g., you should profile your web app from time to time. Another possible scenario is when you don’t have access to the server but some other person does, so you can simply provide him/her with profiling tools and a batch file.
How does it work? In short, you copy console tools to the server and either run the app under profiling (the app pool will be restarted) or attach the tool to the running application pool (w3wp.exe). But when it comes to getting snapshots, things are a little bit different for memory and performance profiling. Let’s take a look at the details.
Performance profiling
Download the zip archive with the ConsoleProfiler.exe tool and copy/unpack it to the server.
Now, you should start profiling of the application pool that hosts your application: you can either attach to an already running app pool or start a new one under profiling. Starting the new one doesn’t give you any advantages over attaching, so, in this article, we’ll take a look only at the latter (you can though still find all the details in the dotTrace documentation).
To attach ConsoleProfiler.exe to the running app pool: ConsoleProfiler.exe attach 1234 --save-to-snapshot.dtp
Where 1234 is the process ID of the corresponding w3wp.exe process
When it comes to taking performance snapshots, things get more a bit more complicated. Unlike dotMemory, you cannot take a snapshot instantly, as it simply doesn’t make any sense: you should see how your app behaves on a time interval. So, you have two options:
Get a snapshot by timeout: ConsoleProfiler.exe attach 1234 --save-to=snapshot.dtp --timeout=5m
Here the snapshot will be taken after 5 minutes, then the profiler will detach from the process. Image may be NSFW. Clik here to view.
Get a snapshot on process exit. The ConsoleProfiler.exe tool will take a snapshot once the profiled application successfully finishes its work (so, if the app is “killed”, no snapshot is collected). To make this happen, you can, for example, Recycle the corresponding application pool in the IIS Manager. Image may be NSFW. Clik here to view.
Copy the resulting snapshot to the computer with installed dotTrace and open the snapshot.
Memory Profiling
It’s a little bit easier with memory profiling: first of all, here you can instantly get a snapshot, and second, with the dotMemory.exe tool you can get snapshots by sending commands to stdin.
Download the zip archive with the dotMemory.exe tool and copy/unpack it to the server.
Now, you have two options for getting a memory snapshot:
Attach dotMemory.exe to the running application pool and instantly get a snapshot: dotMemory.exe get-snapshot 1234 --save-to-dir=C:\Snapshots
Where 1234 is the process ID of the corresponding w3wp.exe process
Run the application pool under profiling (if the pool is already running, it will be restarted): dotMemory.exe start-iis --trigger-timer=30s --open-url=localhost/myapp --use-browser=Chrome
Where --open-url=localhost/myapp is the URL of your application.
In case you’ve chosen to run the app pool, you cannot instantly get a snapshot. Instead, you should:
get a snapshot by condition: e.g. when --trigger-timer=30s is specified, snapshots are taken each 30 s
get a snapshot by sending a command to stdin: ##dotMemory["get-snapshot"]
As with dotTrace, get a snapshot on process exit (e.g. recycle app pool in the IIS Manager)
For more details on how to work with the dotMemory console profiler, please refer to the dotMemory documentation.
Copy the resulting snapshot to the computer with installed dotTrace and open the snapshot.
Memory dumps (only memory profiling)
Image may be NSFW. Clik here to view.
But what if, for some reason, copying and running third-party tools on the server is not possible at all. Well, if it is about memory then your last resort is memory dumps.
It can be taken with a number of tools, with the two most popular being Task Manager (comes with the operating system) and Process Explorer.
Image may be NSFW. Clik here to view.
When creating a dump of a 32-bit application with Task Manager, make sure you use a 32-bit version of the tool that can be found in C:\Windows\SysWOW64\taskmgr.exe.
Now, all you have to do is simply copy the dump to your computer and open it in dotMemory using the Import Dump command.
Image may be NSFW. Clik here to view.
That’s it! We hope this post was useful and helped you to better understand what the possible options you have are when it comes to profiling an app running on a server. If you still have any concerns or your profiling scenario cannot be covered by any of the tools mentioned above, please tell us in the comments to this post.
A month ago we released ReSharper Ultimate 2017.3.2 with lots of fixes. We didn’t waste any time and worked hard this month to prepare something new for you again. Today we open the ReSharper Ultimate 2018.1 Early Access Program.
ReSharper C++ adds Debug step filters to specify functions, which should be automatically stepped over during debugging. It also adds a new typing assist to remove trailing whitespaces on Enter, and a new inspection to find usages of deleted functions.
dotMemory now displays virtual collectible references as Collectible instead of Unresolved.
dotPeek adds support for the decompilation of dictionary initializers and null-conditional operators. It has also learned to show the metadata subtree (headers / directories) for unsupported files and file description for an assembly in the Properties toolwindow.
For a full list of issues fixed in the first EAP build, please refer to EAP notes for ReSharper and ReSharper C++.
TL;DR: ReSharper 2018.2 will require having .NET Framework 4.6.1 installed.
Starting with the next ReSharper 2018.2 release, we will require having .NET Framework 4.6.1 installed on your machine. Earlier versions of ReSharper will continue to work on .NET Framework 4.5.
Why is this changing?
With the .NET Framework evolving rapidly in the past years and Microsoft having stopped support for .NET Framework 4, 4.5 and 4.5.1 over two years ago, updating the required .NET runtime for ReSharper is a logical next step.
Newer versions of the .NET Framework come with numerous improvements, such as performance, security and Windows Presentation Foundation updates. The NuGet client SDK used by ReSharper also requires .NET Framework 4.6 or higher. Making use of the newer, modern runtime brings along these improvements and will greatly benefit our users and opens up new possibilities!
Thanks to this upgrade, the ReSharper codebase can now target .NET Standard 2.0 (and .NET Core), so that for example our Command Line Tools and Remote Profiling Tools will eventually no longer require a full .NET Framework installation at all. This also helps our (non-UI) tools to run on Linux and Mac OS X with better quality. The future is bright!
What does this mean for me?
Older operating systems, such as Windows XP, Windows Vista, Windows Server 2003 and Windows Server 2008 Service Pack 2 will no longer support ReSharper 2018.2 and newer. Earlier ReSharper versions will continue to work.
If you are on a modern operating system or are using Visual Studio 2015 or newer, the .NET Framework 4.6.1 is already installed and will support working with ReSharper 2018.2.
Will I need to retarget my own projects as well?
No. The .NET Framework 4.6.1 runtime is only required to be able to run ReSharper.
Being a productivity tool for .NET developers, we strive for compatibility with as many versions of the .NET Framework and Visual Studio as possible. Projects targeting e.g. .NET 3.5 or .NET 4.5 will still be supported in ReSharper 2018.2, and continue to benefit from rich code editing and code generation features, code analysis and quick-fixes, powerful refactorings, excellent navigation and more!
ReSharper gets a significant number of bug fixes (based on more than 260 requests) and a bunch of features and improvements as highlighted below:
C# 7.2 support has been finalized by adding the missing pieces to the puzzle: non-trailing named-arguments, private protected access modifier, leading underscores in numeric literals, in parameter, ref readonly returns and locals, readonly struct type, ref struct type, and conditional ref operator. Now, if your code follows the latest language version – there’s no more red code!
Navigation features improved: Go to File Member gets a new grouping for better presentation of multiple classes in a single file; Recent Files shows Go to File underneath its search results; Search Everywhere adds a Unit Test filter; and Find Usages now has a disambiguate dialog with a suggestion to look for default constructor usages.
C# 7.x support has been improved by adding more options to code style, inspections, quick-fixes, and context actions for deconstruction and discards.
.editorconfig file can now be used to set inspection severities for any scope: for the whole solution, for a project, or even for a specific file. Also, ReSharper now reads code style settings (Code Editing | C# | Code Style) from .editorconfig files and extends its support for Roslyn language conventions. In addition, the inspection severity settings can be read from a project’s DotSettings file.
Value Tracking, the Introduce variable refactoring, and the .foreach/.var postfix template now support C# 7.x features.
A couple of handy features around code comments have been added.
ReSharper Build engine now supports Pre-/Post-build tasks.
The option Remember last search is now enabled by default.
As far as other ReSharper Ultimate tools are concerned:
ReSharper C++ 2018.1 comes with two new major features: Debug Step Filters which lets you avoid stepping into specific functions during debugging, and Includes Analyzer which helps you investigate the dependencies between the header files that affect compilation time. Other updates include a redesigned Go to File Member dialog, new code inspections, and a command-line tool to perform code cleanup.
dotCover 2018.1 has redesigned two of its vital features: continuous testing mode can be turned on for any unit test session instead of running a separate continuous testing session, and coverage information is now shown in a separate Unit Test Coverage window, instead of a per-session Coverage tab. dotCover console runner gets the ability to cover arbitrary managed processes and services (analyze-everything, analyze-service) and send the get coverage snapshot command to the running instance of the console tool. And last but not least, coverage analysis performance has been improved.
dotMemory 2018.1 comes with many minor user interface improvements. The most significant change is the reworked Analysis Subject panel. Now, it’s much easier to navigate your analysis path.
dotPeek 2018.1 can now decompile the async Main method, dictionary initializers, null-conditional operators, and await inside catch/finally blocks.
dotTrace 2018.1 has received a set of bug fixes and minor performance improvements.
Watch the following video for a summary of what is new in ReSharper Ultimate 2016.3, or read on for the main highlights of this release:
ReSharper
In addition to 700+ fixes, major highlights of ReSharper 2016.3 are the following:
Visual Studio 2017 RC initial support. All ReSharper Ultimate tools now support Visual Studio 2017 RC, including the new .csproj based .NET Core projects. Please note that though Visual Studio 2017 is marked as “RC” there are a number of features and architectural changes that are currently marked as “preview”. As such, we are still working on support for some of these new Visual Studio features, such as lightweight solution load and .NET Core unit testing.
Early support for C# 7 and VB.NET 15. ReSharper 2016.3 learns to understand VB.NET 15 and C# 7 binary literals and digit separators. C# 7 local functions are supported with a set of code inspections, such as Possible System.NullReferenceException, Access to disposed closure, and Access to modified closure. C# 7 out variables, pattern-matching in is expressions and switch cases are also supported. Image may be NSFW. Clik here to view.
New code generation actions. Generate Relational members action helps you automatically overload relational operators (>, <, ≥, ≤) and/or implement IComparable and IComparable<T> using selected fields and properties. Generate Relational comparer creates a comparer class derived from Comparer using selected fields and properties. Generate Dispose pattern action helps you generate the implementation of IDisposable with optional nullability checks and destructor for unmanaged members.Image may be NSFW. Clik here to view.
New quick-fixes and context actions. ReSharper 2016.3 adds a new quick-fix to Introduce fields and auto properties from all unused parameters. This is an extension to the existing quick-fix that will introduce a field from a single constructor parameter, but if you extend the Alt+Enter menu item, it will now apply to all unused parameters at once. Image may be NSFW. Clik here to view.
The Introduce property quick-fix also includes a Configure default menu item, which will set what kind of property is generated by default. There's also a new context action on fields of type Lazy to introduce a property to encapsulate fieldname.Value.
New Transform Parameters refactoring is based on two existing refactorings: Transform Out Parameter and Extract Class from Parameters. It can be invoked on a method declaration and will rewrite the method’s parameters, changing incoming parameters to a new class, or a tuple, and optionally creating a new class for return value and any out parameters. Image may be NSFW. Clik here to view.
ReSharper's unit testing assistance is now available for NUnit and xUnit.net unit tests in ASP.NET Core and .NET Core projects in Visual Studio 2015.
Navigation and search improvements:
The Find Results window now works asynchronously, meaning that you can work with the results tree while usage search is still in progress. The Show in Find Results button becomes available in the pop-up as soon as you invoke Usages of Symbol (Shift+Alt+F12). So you can just click it or press + to go on working with the code while the search continues in the Find Results window. Image may be NSFW. Clik here to view.
Recent Files can now delete entries with the Delete key, and both the Recent Files and Recent Edits pop-ups will now show the path of the file, to avoid confusion with similarly named files.
Go to Text now supports new formats of content files, such as .less, .hbs, .coffee, .scss, .dart, .as, .styl.
There is a new setting to remember the last search in Go to Everything, Go to Text and other search actions.
ReSharper Build receives its own Build Results window, which lists build warnings and errors. You also get more control over how you want to see the results. You can see them as a flat list, or enable grouping, to show by a mixture of project, folder and file. Or you can use ReSharper’s semantic knowledge of the file to group by namespace, type and member. Image may be NSFW. Clik here to view.
Moreover, ReSharper Build now gets its own implementation of NuGet restore.
TypeScript, JavaScript and JSON support improvements:
Go to Implementation now works for TypeScript types too: you can jump from a base type or member to any of its implementations, bypassing intermediate steps in the inheritance chain.
A new quick-fix in TypeScript lets you quickly add type guards to disambiguate unresolved symbols.Image may be NSFW. Clik here to view.
Structural Navigation (Tab or Shift+Tab) now works in JavaScript, TypeScript, and JSON.
Initial support for TypeScript 2.0.2 (“2.0 RC”): boolean, number and enum literal types.
The Encapsulate Field refactoring, which helps you quickly create a property for a field and optionally replace usages of the field, now works in TypeScript.
Optimized memory usage for TypeScript caches.
TypeScript support gets code completion for literal types, as well as a number of formatting fixes for JSX/TSX files.
Extended language injections. In addition to regular expressions and HTML, ReSharper 2016.3 lets you inject CSS and JSON in C#, JavaScript, and TypeScript strings. There are two ways to do so: you can either use the Mark as context action or you can use comments with the special syntax: //language=javascript|html|regexp|jsregexp|json|css Image may be NSFW. Clik here to view.
In addition, ReSharper now automatically injects languages in certain known scenarios, such as injecting JavaScript into AngularJS templates, or CSS in jQuery's $[] indexer.
ReSharper 2016.3 might now suggest you to use some of its features that can increase your productivity. In case it notices that some operation can be performed more efficiently, it would show a pop-up with a suggestion. You can enable the feature it suggests, read more about it, or disable further suggestions.
New options page (Code Editing | Third-Party Code), which allows adding C++, JavaScript, TypeScript, CSS, HTML and JSON files, folders and wildcards to be treated either as "skipped" or "library". ReSharper will completely ignore "skipped" files, and treat "library" files as read-only indexed for navigation, but with no inspections, quick-fixes and refactorings.
Assembly Explorer can now load assemblies directly from nuget.org or from any NuGet package source. Image may be NSFW. Clik here to view.
Stack Trace Explorer now lets you open external stack traces faster: if you copy a stack trace that contains symbols from the currently opened solution and then switch focus to Visual Studio, ReSharper will automatically load it to the Stack Trace Explorer without the need of pressing any shortcuts.
ReSharper C++
ReSharper C++ 2016.3 comes with 180+ fixes and the following set of larger improvements:
Visual Studio 2017 RC initial support: Just like the other tools in the ReSharper Ultimate family, ReSharper C++ 2016.3 can be installed into Visual Studio 2017 RC, but please note that in order to work with ReSharper C++ you should set Enable Faster Project Load to false under Tools | Options | Text Editor | C/C++ | Experimental.
New typedef refactorings. The Introduce typedef refactoring allows you to quickly create a typedef for the selected data type and replace this data type and all its occurrences with the newly created typedef. The Inline typedef refactoring does the inverse: it replaces an existing typedef with the actual data type. Image may be NSFW. Clik here to view.
Postfix completion and templates: Inherited from the mainline ReSharper, postfix code completion allows you to focus on your data, rather than the syntax. When you type a dot (.) or an arrow (->) after an expression, ReSharper C++ will suggest free functions that would accept that expression as the first parameter. ReSharper C++ 2016.3 gets some postfix template goodness as well. You can now quickly wrap an expression with one of the following templates: if, else, while, do, return, switch and foreach. Image may be NSFW. Clik here to view.
Catch support. In addition to Boost.Test and Google Test frameworks, unit testing assistance is now extended to support the Catch C++ test framework. Other unit testing improvements include support for Boost.Test in Boost 1.62 and improved performance on dynamic tests. Moreover, unit tests are now automatically updated for externally changed files.
C++ code analysis from the command line. Starting from this update, ReSharper C++ code inspections are available via InspectCode, a free command line tool that allows running ReSharper C++ inspections without opening a solution in Visual Studio. Image may be NSFW. Clik here to view.
Enhancements in Quick Documentation: ReSharper C++ 2016.3 can display rich, syntax highlighted tooltips for C++ code elements. The tooltips will display function and variable types, as well as documentation. C#-style XML documentation comments are also sometimes used for C++ symbols. With ReSharper C++ 2016.3 they are correctly displayed in the Quick Documentation pop-up (Ctrl+Shift+F1) and in the quick info tooltip. Image may be NSFW. Clik here to view.
Third-party code settings page now allows to exclude files from indexing, so ReSharper C++ will ignore "skipped" files, and treat "library" files as read-only.
Support for nested namespace definitions introduced in C++17 and a context action to use the new syntax for nested namespaces.
New options for C++ code formatter: "Spaces within parentheses in cast expressions", "Align chained method calls", "Align chained binary expressions" and "Place enumerators on new line".
Other tools in ReSharper Ultimate family also received their shares of improvements. First of all, dotCover 2016.3, dotTrace 2016.3 and dotMemory 2016.3 support .NET Core applications profiling and coverage and provide initial support for Visual Studio 2017 RC. Read on for the list of product-specific changes.
dotCover
Reworked coverage highlighting: new highlighting engine in dotCover 2016.3 reveals both coverage status and unit test status. A marker in the text editor shows red if any tests related to the current statement are failing, green if all tests are passing, and grey if there are no tests covering this statement. Image may be NSFW. Clik here to view.
New filtering options that allow easy selection of what code should be covered: all assemblies, everything except System and dotCover assemblies, or only solution assemblies without dependencies.
Multi-selection for nodes in the coverage tree.
dotTrace
dotTrace 2016.3 provides a wide set of improvements for its Timeline Viewer, for instance:
In dotTrace 2016.3, Timeline Viewer incorporates Subsystems feature from the Performance Viewer. To recap, each subsystem just groups calls made within a certain namespace or assembly. It is very handy for a quick estimation of how time in a particular call subtree is distributed among various components: user and system code, WPF, LINQ, collections, strings, and more. Image may be NSFW. Clik here to view.
New Debug Output filter that can be enabled to focus on what your application writes to the debug output, e.g. with the Debug.Write system method.
The new Native Memory Allocation event filter allows you to see what methods are making the allocations and analyze all issues related to native memory: potential memory leaks, issues with unmanaged components used by your managed code, and others.
The Call Stack window in dotTrace Timeline gets a whole bunch of enhancements in 2016.3. The Show system functions option that was helpful when analyzing methods’ own execution time is back again. The Top Methods list now shows not only methods own time, but total time as well. Moreover, now you can click on a method’s own or total time in Top Methods or Call Tree. This will apply a filter by a corresponding method or by a method and its subtree. The Top Methods list now follows your selection in Call Tree.
In addition there is a new Events window that shows you a list of events occurred in the profiled application: file operations, JIT, SQL queries, and more. Selecting an event will give details of the event, including timestamp, duration and call stack: Image may be NSFW. Clik here to view.
dotMemory
dotMemory 2016.3 adds new inspections to check your application on finalized objects and objects queued for finalization. A new Finalizable objects inspection on the overview page shows such objects sorted by their type. Image may be NSFW. Clik here to view.
dotPeek
dotPeek 2016.3 introduces new ways to explore metadata of .NET assemblies. You can now dig through all metadata items (tables, blobs, strings, etc.) right from the Assembly Explorer, which enables you to automatically find and display usages of metadata table items, decode and display values of blob items and explore PE file headers. Image may be NSFW. Clik here to view.
Same as elsewhere in the assembly tree, you can double-click metadata items to decompile and display the corresponding code.
Licensing
If you have an active subscription for ReSharper, ReSharper C++ or ReSharper Ultimate, we encourage you to upgrade to 2016.3 right away. If you are unsure whether your licenses are eligible to use with 2016.3, or if you need a formal quote or any other assistance, please get in touch with JetBrains sales anytime.
Today we welcome you to download our last pre-release build of ReSharper Ultimate 2017.1 and check out all new features and improvements that we’ve been working on since the beginning of this year. In the previous builds we fixed important bugs and added new features that mostly relate to perfecting support for Visual Studio 2017 RTM and C# 7. Today’s EAP build includes noticeable updates to dotMemory, dotPeek and a few other improvements that we are going to cover in this post.
dotMemory command line profiler
dotMemory 2017.1 introduces a console profiler. The dotMemory.exe tool allows configuring and running profiling sessions right from the command line. The tool is a perfect fit when you need to automate the process of gathering memory snapshots in the following cases:
You want to make profiling a part of your continuous integration builds, e.g. this can be a build step that performs profiling of your integration tests.
You want to speed up profiling routines, e.g. when you regularly profile the same application and do not want to start the dotMemory user interface each time.
See how easy it is to take a memory snapshot of a running application (with
The dotMemory.exe tool also allows taking snapshots by a command sent to stdin or by using the profiling API. The most basic tool usage scenarios are described in our Help.
Navigation and search
Finding usages of a specific interface or type becomes even more convenient with a new option in Find Results window to group by kind of usage. There are certain usages like Type conversions which you may want to pay special attention to during the development process. And grouping helps here a lot. The filter was also updated so that you can select specific usage occurrences. Image may be NSFW. Clik here to view.
We’ve also added a small improvement that makes it possible to search for exact matches using quotes.
Go to Everything receives an option to filter the results using a special syntax. Just type ‘/’ to see all available filter options: Image may be NSFW. Clik here to view.
dotPeek portable PDB support
dotPeek can now generate not only traditional PDB files which are Windows-only, but also Portable PDB files. The type of the generated PDB is determined automatically and depends on the selected assembly. dotPeek Symbol Server supports generation of the Portable PDB files as well.
It is possible to explore the contents of the Portable PDB associated with the assembly (standalone or embedded) which is presented in the same way as the assembly metadata. For the associated Portable PDB you’ll see a corresponding subtree in the Metadata tree.
And finally, you can use sources embedded in the Portable PDB for navigation purpose.
Code formatting
All in all, ReSharper 2017.1 brings lots of enhancements to code formatting. EAP 6 adds two more options:
In C# you can force line breaks in a ‘switch’ statement after the ‘case’ label statement or put each section on a single line.
In HTML, CSS and XML you can add line feed at the end of the file.
Other updates
We’ve added support for the routing attributes in Razor Tag Helpers. Code completion, navigation and find usages commands, Rename refactoring are applicable to such attributes.
dotTrace timeline profiling of ASP.NET Core Web Application started to work with the new version of CoreCLR. If you were affected by this issue you need to upgrade your project to use .NET core 1.1.1.
We fixed issue with profiling Silverlight applications (PROF-634) by redesigning Core API so that now it supports all targets: Desktop (both Core API and Self API), Silverlight and CoreCLR. WCF profiling in Visual Studio 2017 RTM is now also supported (PROF-636).
Join us Thursday, April 6, 16:00 – 17:00 CEST (check other timezones) for our free live webinar, Exploring .NET’s Memory Management, with Maarten Balliauw.
In this webinar, we’ll take a trip down memory lane and look into how .NET memory management works. We’ll start off with the .NET Garbage Collector (GC) is really cool and look at how it helps providing our applications with virtually unlimited memory, so we can focus on writing code instead of manually freeing up memory. But how does .NET manage that memory? What are hidden allocations? Are strings evil? It still matters to understand when and where memory is allocated. In this talk, we’ll go over the base concepts of .NET memory management and explore how .NET helps us and how we can help .NET – making our apps better. Expect profiling using dotMemory, Intermediate Language (IL), and using ClrMD to mimic some inspections dotMemory provides.
Image may be NSFW. Clik here to view.Maarten Balliauw is Developer Advocate at JetBrains and loves building web and cloud apps. His main interests are in ASP.NET MVC, C#, Microsoft Azure, PHP and application performance. He is a frequent speaker at various national and international events and organizes Azure User Group events in Belgium. In his free time, he likes brewing his own beer. Maarten’s blog can be found at http://blog.maartenballiauw.be.
This year’s first major release of ReSharper Ultimate is finally here with an ultimate support for Visual Studio 2017! We invite you to download the 2017.1 update and check all the long-awaited features, which you can read about in this post. Image may be NSFW. Clik here to view.
Along with 600+ fixes in ReSharper and 110+ fixes in ReSharper C++ this release comes with the following major improvements:
ReSharper 2017.1 can now work with solutions loaded in a lightweight mode. When you use the Open Folder option, ReSharper sees all the files in the folder and supports .xml and .js file types. Move to Folder refactoring works in this mode.
ReSharper also respects the current target framework context, which is set by the drop-down at the top of the editor window. You’ll find more details about ReSharper’s support for the latest Visual Studio version in the video below:
C# 7 support
ReSharper receives a lot of new inspections, introduces new quick-fixes, and updates existing ones to support C# 7 language features.
We’ve extended ReSharper’s support for local functions and added two context actions that allow you to convert lambda expression or anonymous method into a local function and convert local function into a regular method. There’s also a new quick-fix that suggests converting a read-only delegate variable into a local function.
Join null check with assignment quick-fix has been implemented to support throw expressions. It makes the code more readable by combining the assignment, the null-coalescing operator, and throw. The existing context action Convert to ‘?:’ operator and the
.throw
postfix template also support C# 7 throw expressions.
Watch the video to see how ReSharper helps you use the new C# 7 features:
Unit testing
ReSharper’s unit testing works in both project.json- and .csproj-based projects in Visual Studio 2017 RTM. It discovers and runs MSTest and xUnit tests and supports code coverage and profiling as well as targeting multiple frameworks. NUnit tests that target .NET 4.x frameworks are supported. There’s also DataRow support for MSTest v2. Image may be NSFW. Clik here to view.
Note that ReSharper currently doesn’t support continuous testing for .NET Core unit tests. This will be fixed in the next updates.
EditorConfig support and other code style improvements
Maintaining a consistent code style throughout your code bases is important since making the code more readable for all project contributors saves everyone’s time and even helps you avoid some errors. ReSharper 2017.1 provides several new features for keeping your code neat and clean. Watch the video for a quick overview of some of the updates and read on for more details.
EditorConfig support
EditorConfig offers a convenient way to share code style settings with colleagues who use different editors and IDEs. EditorConfig support in ReSharper 2017.1 is enabled by default. Below is an example of .editorconfig file settings supported by ReSharper:
root = true
[*]
# Most of the standard EditorConfig properties are supported
indent_size=2
max_line_length=100
# Most of Roslyn EditorConfig properties for Visual Studio 2017 are supported
csharp_space_between_parentheses=expressions, type_casts, control_flow_statements
csharp_new_line_within_query_expression_clauses=true
# Custom EditorConfig properties for every code formatting setting available in ReSharper options
resharper_csharp_brace_style=next_line
resharper_csharp_blank_lines_around_invocable=2
For more details on what EditorConfig properties ReSharper understands, refer to the Using EditorConfig help section. And watch the video to see how ReSharper uses EditorConfig to share formatting settings across your team:
Layered settings for tabs and indents
ReSharper’s layered settings feature is a great tool to maintain a consistent code style if most of your team members use ReSharper. Now it is extended with Tabs and Indents settings for all supported languages.
Image may be NSFW. Clik here to view.
Autodetection of the indent size and style
When you contribute to existing projects you may not have enough time to fine-tune code style settings. This is where a new ReSharper’s feature comes in handy. ReSharper now automatically detects and sets the indent size which is used in a file. This feature is disabled by default and can be enabled on the General Formatter Style ReSharper’s options page.
File formatting info
The new File Formatting Info window displays the sources of code style settings, including scopes and properties defined in all active
.editorconfig
files, the source of indentation settings and its value, and the status of indent autodetection.
Contextual configuration of formatting rules
The process of adjusting a new tool for your preferred code style can be tedious. To save your time, ReSharper offers contextual configuration of the formatting rules, which is now available in С#, C++, JavaScript and TypeScript. Select some code, press Alt+Enter and choose Format Selection | Configure to see formatting rules that affect only the selected code.
Code style, formatting and cleanup improvements
ReSharper’s Code Cleanup gets usability improvements. Now you can create and configure your custom task-specific profiles right in the Code Cleanup dialog box, simply by pressing Ctrl+E,C. Image may be NSFW. Clik here to view.
ReSharper applies its configured formatting rules to any code you paste. The Reindent option that affects only the indentation is set by default and you can change it on the Editor Behavior options page.
ReSharper 2017.1 introduces new code style settings for C# type members bodies, allowing you to choose between always using a body block, with braces, or using the expression format. ReSharper will mark any incorrect usage and provide a quick-fix to quickly rewrite to the correct style.
Image may be NSFW. Clik here to view.
C# code formatting engine has been significantly rewritten. We’ve fixed a lot of bugs and introduced new formatting options:
The new wrapping engine now handles the alignment correctly
Comma-first wrapping style is supported
Set spaces before and inside the parentheses of ‘nameof’
Choose preferred wrapping style for chained binary expressions
Configurable line breaks in a single ‘case’ statement
Navigation and search
Finding usages of a specific interface or type becomes even more convenient with a new button in Find Results window to group by kind of usage. The filter was updated so that you can select specific usage occurrences. ReSharper also highlights broken or unfinished usages, which helps to determine what’s left to fix. Watch the video below to learn more about the updates to the Find Results window.
The Go to Everything and Go to Text popups support inline commands for advanced filtering of search results: Image may be NSFW. Clik here to view.
ReSharper’s Search & Navigation page adds a new option to open files in the preview tab from everywhere. This option is turned off by default.
Angular 2 templates syntax
ReSharper understands the following elements of Angular 2 templates syntax: template expressions, template statements,
NgFor
directive and template variables. Support is implemented for the
template:
property in Angular
@Component
decorator as well as for pure HTML referenced by
templateUrl:
property in
@Component
. Only relative paths are supported in
templateUrl
. For HTML pages, Angular markup is switched off by default and can be enabled in ReSharper Options (Code Editing | HTML | Editor).
The Rename refactoring works for component tags and for ‘foo’ in
[class.foo]
. Image may be NSFW. Clik here to view.
Component attributes receive support for the Go to Declaration (F12) command.
Code completion works for Angular attributes and component tags, as well as for
[attr.
,
[style.
and
[class.
. Image may be NSFW. Clik here to view.
Note that Angular 1 is not yet supported. You can use the AngularJS plugin for code completion and live templates, if Support Angular markup in HTML pages is set to ‘None’ in ReSharper options.
TypeScript and JavaScript support
We implemented full support for TypeScript 2.1 and initial support for TypeScript 2.2.
In TypeScript 2.1 ReSharper now understands mapped and indexed types, object rest and spread properties, updated logic for literal types, configuration inheritance, untyped imports, combined types normalization, partially annotated signatures, and control flow analysis for implicit any and implicit any arrays. Image may be NSFW. Clik here to view.
In TypeScript 2.2 ReSharper supports ‘object’ type, JSX spread syntax and deriving (extends/implements) from signatures/tuples/intersections/mapped types.
The Rename refactoring in TypeScript works faster for local symbols and gets a new option to disable search for dynamic usage of TypeScript symbols in JavaScript files via a checkbox in the Rename dialog.
The Generate Code menu gets a new option to generate properties or read-only properties for TypeScript classes. The Generate Overriding Members command now calls ‘super’ whenever possible. Image may be NSFW. Clik here to view.
TypeScript gets highlights and quick-fixes for unused imports in ES6 style imports.
You can now speed up your coding in JavaScript and TypeScript by taking advantage of postfix templates: Image may be NSFW. Clik here to view.
ReSharper’s File Status Indicator (the small icon at the top of the Error Stripe) receives a new context menu. With a right-click on the icon, you can quickly toggle not only ReSharper code analysis but also identifier highlightings and Visual Studio code analysis (lightbulb and squiggles). If there are code issues in the current file, you’ll also see commands for navigating between issues of the highest severity level.
Image may be NSFW. Clik here to view.
Note that for large files ReSharper suspends code analysis automatically. In this case, you’ll see a gray Pause icon in the Status Indicator.
ReSharper C++
ReSharper C++ 2017.1 introduces initial support for the Open Folder functionality and CMake-based projects in Visual Studio 2017. If you want to use ReSharper’s unit testing capabilities, you’ll need to configure a test run on the new C++ Tests page in ReSharper options. Please note that support for this kind of projects is still experimental — do let us know if you experience any problems!
Speaking about performance, ReSharper C++ significantly improves its memory usage, including both memory footprint after indexing and memory traffic during indexing. Moreover, the reindexing process should trigger less often during the normal workflow, as ReSharper C++ will not, by default, invalidate includers after preprocessing directives change in an included file.
We’ve enhanced inspections and code cleanup:
The Update file header cleanup task and a set of cleanup tasks to fix common code issues are added Image may be NSFW. Clik here to view.
Control flow inspections are updated to handle class fields in addition to local variables and function parameters Image may be NSFW. Clik here to view.
The inspection Declaration and assignment can be joined is implemented, together with an accompanying quick-fix Image may be NSFW. Clik here to view.
Introduced several custom C++ 11 attributes that can be used to mark
printf
-style functions (RSCPP-15890), functions with side effects (RSCPP-18615), and guard classes for which the Unused variable highlighting should be suppressed (RSCPP-18764)
Theset of postfix templates is extended with beg..end, new, var, const_cast, dynamic_cast, reinterpret_cast, static_cast, make_shared, and make_unique. You can configure the availability of C++ postfix templates and other settings on the Postfix Templates page in ReSharper options. Image may be NSFW. Clik here to view.
ReSharper C++ also improves code formatting:
Indent size and style can be auto-detected
Indenting of preprocessor directives is now supported
Adds new formatter options: Indent namespace members, Space after parentheses in cast expressions and Break line in simple ‘case’ statement
Last but not least, ReSharper C++ supports inline commands for results filtering in Go to Everything and Go to Text popups, and grouping by kind of usage in the Find Results window.
For more details about new ReSharper C++ features please refer to the What’s New page.
dotMemory, dotCover, dotTrace, and dotPeek
You can now attach the dotTrace and dotMemory profiler to running applications using drag and drop. Simply drop a special icon onto the application window you want to profile. Image may be NSFW. Clik here to view.
We’ve introduced dotMemory Command Line Tool (dotMemory.exe) which is extremely helpful when you need to automate the process of gathering memory snapshots. The most basic tool usage scenarios are described in our Help.
Old-style highlighting in dotCover 2017.1 is back again and supports the updated logic to display both tests coverage and test results. There’s also an option to switch between markers and colored background or to display both.
Image may be NSFW. Clik here to view.
Finally, we’ve implemented support for portable PDB in dotPeek. You can generate PPDB files, explore the contents of the Portable PDB associated with the assembly, and use sources embedded in the Portable PDB for navigation purpose.
Image may be NSFW. Clik here to view.
That wraps it up. Please download a free 30-day trial of ReSharper Ultimate 2017.1 and check the new features and improvements.
The recording of our recent webinar with Maarten Balliauw, Exploring .NET’s memory management, is now available:
We’ll take a trip down memory lane and look into how .NET memory management works. We’ll start off with the .NET Garbage Collector (GC) is really cool and look at how it helps providing our applications with virtually unlimited memory, so we can focus on writing code instead of manually freeing up memory. But how does .NET manage that memory? What are hidden allocations? Are strings evil? It still matters to understand when and where memory is allocated. In this talk, we’ll go over the base concepts of .NET memory management and explore how .NET helps us and how we can help .NET – making our apps better. Expect profiling using dotMemory, Intermediate Language (IL), and using ClrMD to mimic some inspections dotMemory provides.
All demos are available on GitHub and come with interactive walkthroughs, mostly. If you have dotMemory installed, you can investigate the results of each demo on your own!
Slides are on SlideShare, and a detailed blog series on the topic is available as well:
In the 2017.1 release, dotMemory introduced a console profiler. Now, using the dotMemory.exe tool, you can perform memory profiling from the command line. Why would you? The short answer would be to automate the process of gathering memory snapshots. There are lots of possible use cases:
You want to speed up profiling routines, e.g. when you regularly profile the same application and do not want to start the dotMemory user interface each time.
You need to profile your application on someone’s computer you don’t have access to (e.g., your client’s) but don’t want to bother him with dotMemory installation and detailed profiling instructions.
Or maybe you want to include memory profiling into your continuous integration builds (though our dotMemory Unit framework could be much handier for this purpose).
Where can I get it?
dotMemory.exe is distributed separately from dotMemory. You can download the tool on the dotMemory download page. Note that dotMemory.exe is freeand does not require you to have the full dotMemory installed.
Now let’s take a look at the most common usage scenarios.
Instantly get a snapshot
The most popular scenario is probably getting a snapshot of an already running application.
1234 here is the process ID. Right after you run the command, dotMemory will attach to the process, take a snapshot, save it to C:\Snapshots, and detach from the process.
You can also specify the profiled application with its process name:
dotMemory.exe get-snapshot MyApp --with-max-mem
or
dotMemory.exe get-snapshot MyApp --all
--all and --with-max-mem options let you avoid ambiguity when multiple processes with the same name are running:
--with-max-mem – a process that consumes most of the memory will be profiled.
--all – all processes with the specified name will be profiled. dotMemory will take snapshots of all processes (snapshot per process).
Get snapshots by condition
Sometimes you may need to track application memory consumption during a long time interval. In this case, you can start your application under profiling and get snapshots only in case a particular condition is satisfied:
a periodic time interval ends (in the example, it’s 30 s):
(--trigger-delay=5s here stands for the 5s delay required to skip application startup phase)
Note that in both examples, we use the start command to start the application. If you want to profile a ASP.NET application, you should use the start-iis command. In this case, IIS and all its application pools will be started under profiling. E.g.:
What if the app you want to profile is already running but you still want to use triggers? Simply use the attach command:
dotMemory attach MyApp.exe --trigger-timer=30s
Get snapshots using stdin messages
If you want to take direct control over the profiling process (i.e., get snapshots at some exact moment), you can do this by sending messages to stdin of dotMemory.exe:
Get a snapshot:
##dotMemory["get-snapshot", {pid:1234}]
If pid is specified, dotMemory will take a snapshot of the process with the specified PID. Otherwise, dotMemory will take snapshots of all profiled processes.
Stop profiling and kill the profiled application:
##dotMemory["disconnect"]
These stdin messages work for all profiling sessions started with start, start-iis, or attach commands.
Moreover, if you want to write a profiling script, you may find it useful that dotMemory.exe is able to send service messages to stdout:
Start of the profiling session:
##dotMemory["connected", {pid: 1234}]
Saving the snapshot:
##dotMemory["workspace-saved", {path: "..."}]
Note that messages sent to stdin must always start from a new line and end with a carriage return. Both stdin and stdout messages have the format of a JSON array.
Get snapshots using API
Of course, we don’t forget about our profiling API. If you control profiling directly from your code using the dotMemory API, run dotMemory.exe with the -–use-api command. E.g.:
dotMemory.exe start --use-api C:\MyApp\MyApp.exe
We hope you’ll find the dotMemory console profiler useful and helpful in automating your profiling routines. As usual, we invite you to download the tool, try it on your own and share your experience.
With every ReSharper update, we get questions around performance. Some users notice a slightly slower solution load, others see a minor indexing lag, and others get bugged by a yellow notification bar stating “Extension ‘JetBrains ReSharper Ultimate’ likely caused 9 seconds of unresponsiveness. Disabling it may improve your experience.” – and yes, we have seen higher values there, too.
We hear you. We use ReSharper to develop ReSharper. It may not always be visible, but we are working hard on improving ReSharper performance. And because those changes aren’t always visible, we are starting a blog series about the minor and major changes that are in the works.
We’ll touch on some high-level things, but will also open up the hood and see what happens underneath.
Note these posts will be long – there’s a lot of context involved. So let’s start at the beginning – a little bit of history!
Visual Studio and ReSharper
Visual Studio services many developers across Windows, the Web and multiple Cloud and Mobile platforms. It builds on years of history, and has gone through a number of changes over the years. New languages and frameworks came about, often with new development paradigms. The C# compiler moved to Roslyn, adding additional code analysis and refactoring features to Visual Studio.
Development workloads are always in motion, and thanks to Visual Studio having a very extensible architecture, it has always been able to follow new development trends and provide a rich IDE experience.
Plugging into that extensible architecture, ReSharper increases Visual Studio value by extending existing features and by providing additional capabilities like additional code analysis rules and quick-fixes, structural search-and-replace, 55 refactorings, improved code generation, build and debugging features, and much, much more – an overview is available in our ReSharper vs. Visual Studio overview.
An additional consideration is that ReSharper doesn’t only extend the latest Visual Studio version. Many of our customers are using previous Visual Studio versions for a variety of reasons, making ReSharper extend Visual Studio 2010 SP1, 2012 (all three updates), 2013 (all five updates), 2015 (all three updates), and all of the updates 2017 continuously brings.
This means ReSharper still knows about project.json, has knowledge of lightweight solution load which was introduced and then removed, and many more.
The point we are trying to make here is that both products are complex in nature. And there is even more complexity! Have you ever thought about how difficult it is for an IDE to work with incomplete, broken code that does not compile? It is what happens all the time while we are writing lines of code… And that broken code can be refactored! We can navigate around our project! There’s code completion! It’s awesome, really, that Visual Studio and ReSharper can do this!
I, for one, would not want to go back to the basic tools we had in 1998 – having a rich IDE is just too good!
The 32-bit cage match
One thing has not changed since Visual Studio’s inception: it has always been a 32-bit process. This means that in the best circumstances (running as a 32-bit application on a 64-bit operating system), it can only consume close to 3 GB of memory. In practice, only about 2.5 GB of memory can be used.
Not all of that space can be used efficiently, as there’s “reserved memory” as well: memory that is pre-allocated for future use, used for communication between processes, used for mapping files from disk, chunks that do not have enough free space to be used by the .NET runtime to store its objects, …
In the remaining usable memory space, it has to host its own functionality, the Roslyn engine, and when ReSharper is installed, the ReSharper engine, too. As well as all actions and commands available throughout the IDE.
If at any point we profile Visual Studio with ReSharper enabled, we can see that a lot of time is spent doing just Garbage Collection (GC) – a good 12% of the time in this snapshot! (this was during a solution load)
Image may be NSFW. Clik here to view.
(Note: as we can see in this snapshot, Visual Studio startup spends a lot of time doing Just-in-Time (JIT) compilation as well – we will touch on that later in this series.)
In 32-bit processes, GC may run more often than is optimal, for example when there is a memory shortage. In a 64-bit process, more objects may have to be sweeped but this will be done less often and at more optimal times because the ceiling is not being reached.
“If only Microsoft would compile Visual Studio as a 64-bit executable! It would ensure there’s more available memory, and everything would be fixed! Right?” Many have been asking exactly that: please make Visual Studio a 64-bit executable. The first comment in that thread mentions this will not be easy. Assemblies may become larger, and the IDE may actually become slower because there is even more memory to manage (garbage collection may take more time and resources).
How is that possible? There are many areas where Visual Studio and ReSharper consume memory, but let’s focus on one of many examples. Both Visual Studio and ReSharper keep a syntax tree in memory. All of the code in our project is parsed into a semantic model and a syntax tree. Roslyn uses immutable trees, which is great when working with syntax, but also means code under churn creates a lot of objects that may not be short-lived and will have to be garbage collected. ReSharper has a different approach with its PSI and how syntax and semantics are modeled and processed in memory.
Some syntax and semantic structures will be generated once and won’t change. So next to short-lived objects, Roslyn, as well as ReSharper end up with having a number of long-lived objects as well. And where do those go in the .NET runtime? Generation 2. And generation 2 garbage collection usually takes longer because the objects have more roots where they are referenced.
Image may be NSFW. Clik here to view.
Is this bad? Not at all. Both Roslyn and ReSharper re-use already known information about our code, keeping the objects containing that information in memory. Our IDE would slow down if these had to be re-created all the time, so keeping them in memory is a good approach. It’s just that when the garbage collector runs, it may take a little longer.
Moving to a 64-bit process will only make the number of objects to scan during a garbage collection (GC) larger, possibly making GC pauses take more time.
In short, it seems 64-bit will not happen soon, if ever. This means Microsoft as well as JetBrains and other extension authors have to resort to clever techniques to provide better performance.
Conspiracy theories!
In this introductory post, let’s get one more question out of the way… Many have been asking us whether JetBrains is intentionally slowing down ReSharper to promote Rider. This is definitely not the case!
Rider can not exist without ReSharper (they share their codebase), and any work we do on one product influences and benefits the other. Having both products running in a different environment (32-bit Visual Studio vs. 64-bit Rider) brings benefits, too. Any problem that exists around performance and memory in ReSharper and Rider can stay unnoticed in Rider but will most probably surface very clearly in ReSharper. Fixes will always benefit both.
ReSharper and Rider target the same audience of .NET developers, and we want to offer them a choice. Some prefer Visual Studio and ReSharper/ReSharper Ultimate, others prefer Rider. We welcome teams to work in mixed environments, where some may use vanilla Visual Studio, other use ReSharper Ultimate in Visual Studio, and another group uses Rider.
Conclusion
In this post, we determined that both IDE’s like Visual Studio and tools like ReSharper are complex in nature. We’ve looked at some of the histories of both products, and have seen that some of that history is not easily changed.
But that does not mean things can’t be improved! In our next blog post, we will look at a number of high-level improvements JetBrains is doing to make ReSharper better and faster. And no, the answer is not as simple as switching to Roslyn… Stay tuned for (much) more!
In the previous post of our ReSharper performance series, we looked at Visual Studio and ReSharper complexity and history, and determined that one of the reasons for degraded performance lies in Visual Studio being a 32-bit process. In this post, we will look at what can be done to overcome that limitation.
We’ve looked at the 32-bit process limitations, and figured out there is only so much memory that can be consumed. So one might ask: why is JetBrains still building their own language engine with ReSharper? Why not just use Roslyn so that there is only one engine in memory instead of two? And as a bonus, ReSharper development may go quicker?
There are a number of reasons for not doing this, as explained in our ReSharper and Roslyn Q&A. A better question would be the following: is it worth replacing a well-oiled engine just to work around the limited 32-bit working set? And how long would it be before that replacement also runs against the boundaries? Surely there are better ways…
Microservices! (in the form of child processes)
How can one go beyond this hard limitation in available memory? As with everything, the answer is microservices. Visual Studio is gradually transitioning into a process with many child processes, where every one of those child processes can consume the amount of memory it needs.
Image may be NSFW. Clik here to view.
This architecture has several advantages: each child process has its own thread pool and can be run on different CPU cores by the operating system. Each child process also has its own memory space and its own garbage collector.
We use the same approach in Rider, our cross-platform .NET IDE, where the IDE is just the UI and a host process, and a lot of the heavy lifting happens in the child processes that are spawned, and this works wonders for performance.
Running multiple processes does present some other challenges. How do you keep them in sync? Do all keystrokes in the editor have to be processed? When we type a class name and then remove it again, does it have to exist in both processes? The reactive distributed communication protocol we use in Rider may be the answer to these questions.
JetBrains is investigating making ReSharper a child process of Visual Studio, instead of being part of the main process.
Async loading of the ReSharper VSPackage
Next to making ReSharper run its own process, we can improve loading the bits that have to remain in the Visual Studio process. We’ll still be able to render menu’s, show refactoring dialogs and keep track of what is happening in the editor.
Visual Studio is really just the Visual Studio Shell, which loads a number of VSPackage instances that contain language features and specific tooling to make it an IDE. Pretty much every checkbox in the Visual Studio installer represents such VSPackage, and ReSharper is another VSPackage instance that can be loaded.
Visual Studio performs delay loading when a package is only needed in certain contexts. Newer versions of Visual Studio allow asynchronous loading of a VSPackage as well, moving the work to a background thread.
JetBrains is investigating loading ReSharper as an asynchronous VSPackage.
Conclusion
In this post, we have looked at one of the ways to make ReSharper performance better: taking it out of process. This brings many benefits: both Visual Studio and ReSharper run in their own process, have their own thread pool, and their own memory space. In addition to that, we are investigating async loading of ReSharper in Visual Studio.
None of these solutions will be the silver bullet by themselves, though. There are other areas that can be improved, and we will look at those in our next blog post!
In the previous post of our ReSharper performance series, we have seen that it makes a lot of sense to explore running it as a separate process. This brings many benefits: both Visual Studio and ReSharper would run in their own process, have their own thread pool, and their own memory space.
By itself, this is not the silver bullet that will fix performance, however. It is a big part, but there are additional areas that can be improved. In this post, we will look at improving startup of Visual Studio and ReSharper.
Visual Studio is essentially a combination of the Visual Studio Shell which provides common functionality and hosts modules defined in VSPackages, and a number of those VSPackages that provide C# editing, web tools, Azure tools, a WPF designer, refactoring tools, and more.
ReSharper’s component model is quite advanced. Components can be loaded when the host starts, when a solution is loaded, just-in-time when needed, … Components are registered using attributes in extension code, and then loaded at the appropriate time. ReSharper loads about 8100 components when Visual Studio starts, and around 2500 components per solution.
While all of that is powerful and allows for extensibility, it comes with a few downsides as well:
Components have to be instantiated at some point. Either when the host process starts (which could be Visual Studio or one of our standalone tools like dotPeek), or when a solution is loaded or reloaded.
All components have to be loaded in one chunk, to ensure interdependencies can be satisfied.
Visual Studio and ReSharper differ in their approach to component load and discovery. Visual Studio caches the component model (which is good but sometimes also needs a gentle nudge), whereas ReSharper transparently invalidates its component cache when any file changes.
The process of scanning components is quite fast, but there is one downside in the current ReSharper architecture: all components are created in a transaction on the main thread. That’s an issue… If scanning and initializing components takes 9 seconds on the main thread, there is a big chance Visual Studio will display the yellow notification bar stating ReSharper slowed down Visual Studio startup.
There is another issue here: Visual Studio lazily loads some of its own components. However, ReSharper sometimes has to force Visual Studio to load these, as a ReSharper component may have a dependency on it. We are working on making ReSharper also use lazy loading for many of these cases, to further reduce the initial startup time.
JetBrains is working on lifting the main thread requirement, so that components can be loaded on other threads. This will also make it possible to load components lazily, on-demand, which will further reduce startup time.
Just-in-Time – JIT compilation
The C# compiler usually does not compile directly to machine code, and instead compiles to Common Intermediate Language (CIL). When we then start a .NET application, that CIL code is compiled Just-in-Time (JIT) and executed by the .NET runtime.
This approach eliminates the need to distribute different executable files for different CPU types and platforms. It helps us ship a single ReSharper assembly, which can be run on a variety of Windows operating systems and even cross-platform as proven by Rider (which uses the ReSharper engine as well).
The process of JIT compilation is highly optimized: the .NET runtime only compiles the CIL code that is being executed, not entire assemblies.
Now let’s look back at ReSharper’s component composition we just talked about… On startup, a lot of assemblies are loaded, and because we have to determine if initialization work has to be done a lot of code has to be JIT-ed and compiled at startup. The fact that this all runs on the main thread also means the main thread is affected by this JIT compilation.
So how can we solve this? One approach would be to skip JIT and use explicit compilation by converting all of the CIL code to machine code ahead-of-time (AOT), for example using ngen.exe (Native Image Generator).
We have tried ngen.exe with ReSharper, but this was not practical for a number of reasons:
If we run AOT compilation at JetBrains, installer size would become much larger because assemblies for different platforms would have to be shipped.
If we run AOT compilation as part of installing ReSharper, installation would take longer to run and would require running with elevated privileges, which many of our customers don’t allow.
Instead of doing ahead-of-time compilation, we will be taking another approach which is somewhere between JIT and AOT compilation. Similar to using the ProfileOptimization class, instead of performing JIT on the main thread, we will ship a runtime profile with ReSharper (and other tools) so that the .NET runtime can perform JIT in a more efficient manner:
The profile describes the classes and methods that will be accessed on load, instead of having to rely on late binding to discover which CIL code has to be compiled.
Since we have that description, we can run the JIT compilation over multiple background threads, speeding up the entire process.
If we profile startup of dotPeek, our standalone decompiler that uses a number of components from ReSharper, we can see most of the JIT work normally happens on the main thread. On a 4 core/8 thread machine, starting dotPeek takes roughly 12 seconds.
Image may be NSFW. Clik here to view.
When making use of a JIT profile, things look different. The main thread is still very active during startup (it’s the main thread after all), but a lot of the JIT work is moved to separate threads (the CLR Worker threads in the below screenshot). On the same 4 core/8 thread machine, startup now only takes around 7 seconds.
Image may be NSFW. Clik here to view.
You may have noticed that the second snapshot does more JIT than the first snapshot (17 031 ms as opposed to 7 740 ms). If you caught this, great! The second, faster version is indeed doing much more JIT compilation at startup. This is due to the JIT profile we created, which contains more classes and methods than what we need to be available just after start. This gives the JIT compiler some additional work, but overall application load is faster, and having these extra methods “ready to be used” pays off during application usage.
With ReSharper, we’re seeing promising results where loading components using this technique takes ~5 seconds, instead of ~9 seconds on average right now. Work in progress!
JetBrains is working on improving Just-in-Time (JIT) compilation performance, as well as making it use multiple background threads. This will greatly reduce startup time.
Too much work on the UI thread
Previously, we looked at a performance snapshot of Visual Studio and determined quite a lot of garbage collection is happening. However, we skipped over another interesting item. Have a look at the main (UI) thread here:
Image may be NSFW. Clik here to view.
We have already seen that component composition in ReSharper is a cause of the yellow Visual Studio unresponsiveness notification, as well as Just-in-Time (JIT) compilation.
Being an active participant in your Visual Studio coding experience, ReSharper does have to send messages to the main/UI thread, e.g. to add a code analysis warning squiggle in the editor, or render additional elements in the UI. It turns out that if ReSharper is invoking any Visual Studio functionality that is unresponsive, ReSharper can be blamed for the unresponsiveness notification – even though it is not the real culprit.
A UI unresponsiveness or crash notification means only that one of the extension’s modules was on the stack when the UI was unresponsive or when the crash occurred. It does not necessarily mean that the extension itself was the culprit. It is possible that the extension called code which is part of Visual Studio, which in turn resulted in unresponsive UI or a crash.
JetBrains is working on making sure ReSharper does not interrupt the UI message pump for too long, which will reduce false notifications. In combination with doing less work on the UI thread, this helps improve overall performance.
Conclusion
So far in this series about ReSharper performance, we covered a number of high-level improvements JetBrains is making in this area. Unfortunately, there is no silver bullet. A combination of efforts will have more effect, and that’s why:
We are investigating making ReSharper a child process of Visual Studio, instead of being part of the main process.
We are working on making it possible to load components on background threads.
We are investigating the possibility to create components on-demand, further reducing startup time.
We are working on improving Just-in-Time (JIT) compilation performance, as well as making it use multiple background threads.
We are working on making sure ReSharper does not interrupt the UI thread and message pump for too long, which will reduce false unresponsiveness notifications.
All of these improvements are architectural in nature, and will start surfacing in the next versions of ReSharper and Rider.
There’s one type of performance issues we haven’t looked at yet: the smaller, local performance problems that tend to accumulate over time. These are often the type of issue that only becomes visible when software is used in varying environments.
In our next and final post of this series, we will look at a number of smaller performance improvements that were made in the latest ReSharper 2018.1 and Rider codebases. Keep an eye out for our next blog post!
In previous posts of our series about ReSharper performance, we’ve looked at a number of high-level, architectural improvements JetBrains is making in terms of performance. We also discussed software tends to accumulate smaller, local performance problems over time.
In this post, we are going to highlight noticeable changes we’ve made in ReSharper 2018.1 and 2018.1.1 to improve performance for many scenarios.
There are some interesting gems in there. Let’s have a more in-depth look at them!
The ReSharper and Rider issue tracker
In case you didn’t know this: here at JetBrains, we have a public issue tracker for all of our products. For example, issues for ReSharper are available here, Rider issues can be seen here. Anyone can create new issues, describe how to reproduce a problem, attach screenshots, and more.
It’s also possible to create new issues from inside our products. For example, ReSharper allows collecting a performance snapshot and sending it to JetBrains. This is extremely helpful for us: using this information, we get great insights in the various environments and use cases our products are used in.
In the remainder of this post, we will look at a number of issues that were submitted by developers from all around the world. We want to thank everyone who made the effort of reporting them, and helping to make ReSharper and Rider better for everyone!
Performance issues fixed in ReSharper 2018.1
As with every release, ReSharper 2018.1 shipped with new features as well as fixes and improvements to performance issues.
RSRP-467444 – Huge delays when switching between file tabs with different effective .editorconfig
In the previous version, ReSharper collected indentation settings from .editorconfig, .clang-format, and layered-settings files for each opened code file and changed Visual Studio settings on the fly, which could sometimes be slow. As a result, switching between files caused delays.
In 2018.1, we stopped changing Visual Studio settings in accordance with .editorconfig. Instead, we now override Enter and Tab key handlers to keep .editorconfig file indentations. “Smart indent on Enter” and “Use ReSharper formatter settings on Tab” settings were added to ReSharper | Options | Environment | Editor | Editor Behavior.
RSRP-466697 – MvcUtil.IsPossibleViewsFolder is very slow in completion
Some time ago, we added a new scope to the File Templates feature: Razor Views Folder. Since technically there is no difference between calculating availability for File Templates and Live Templates, “Razor Views Folder” scope is calculated even when IntelliSense is called, which can take lots of time in some cases. However, there is no need for File Templates in IntelliSense popup. ReSharper now stops calculating “Razor Views Folder” scope on preparing data stage for IntelliSense popup.
RSRP-468843 – Loading 8-project solution with an Aurelia-based web site – UI freeze takes around 1 minute in total
There were lots of problems fixed : we’ve optimized processing of JavaScript files with Source Maps; we’ve refactored reading JS files from disk so that instead of being a synchronous operation on the UI thread, it’s now running on a background thread along with building caches; more tasks were made lazy to prevent running them simultaneously during solution load.
RSRP-468809 – VS UI freeze when running lots of tests
ReSharper Unit Test runner reads assemblies with tests from disk to discover all target frameworks for every single test. It turns out that doing so involved lots of redundant I/O operations, and most tests are stored in the same assembly, there’s no need to read the file over and over again. We removed redundant I/O operations by adding an assemblies cache, and the delay went away.
RSRP-464284 – [Performance Report] Run xUnit.net unit test with data factory freezes UI on first run (this was a private ticket)
A whole tree in a unit test session tab used to be updated on adding just a few elements to the tree. We disabled full tree update when the number of modified nodes is low, and now redraw/add/remove only these nodes without touching others.
RSRP-468914 – [Performance Report] Very slow solution loading snapshot
Reading properties for C++ projects took much more time than we expected. We got in touch with our contacts at Microsoft, and they provided us guidance on how to read some of them in a quicker way to optimize access time.
Find Usages for compiled elements (symbols from libraries) executed the same operations multiple times due to a lot of old code with a funny smell. After rewriting the code to make sure that the required data is only queried once, Find Usages became way faster.
We added a cache inside the “Find Inheritors” search mechanism that is at the core of Go to Derived Symbols, Find Usages and most refactorings. We are expecting all these ReSharper features to get a performance boost in code bases with huge inheritance hierarchies.
Rename refactoring – Multi-threaded Find Usages (this was a private ticket)
The Find Usages stage of the Rename refactoring now uses multithreading. Because this is the most time-consuming stage of executing a rename, expect a significant overall speed-up when using this immensely popular refactoring.
RSRP-460529 – [Performance Report] 40-second UI freeze when I in-place rename a CSS class name from an .ascx page in DNN
We moved our internal text search from a word-based index to a trigram index several releases ago. It allows us to significantly decrease the number of files for further processing since we can definitely identify which files do not contain a particular word.
Unfortunately, some of the search providers (including CSS ones) were not fully updated to get all trigram benefits and still used an old, intermediate layer between the provider and the index. We removed this intermediate layer and now CSS search providers use trigram index directly. After migration to trigram index, we can query names like “class-table-id” as a single word instead of having to divide it into separate parts.
RSRP-467468 – Set ShouldBuildPsi=False for XAML-generated files .g.cs and .i.g.cs
Before the fix, we filtered some entities from .g.cs and .i.g.cs files despite already having this information from .xaml files. Since filtering takes time, we have stopped redundantly analyzing .g.cs and .i.g.cs.
RSRP-468715 – [Performance] Any navigation takes about 2 seconds if Todo Explorer is opened
This is a classic example of fixing one thing and breaking something else along the way. The logic of updating the To-Do Explorer involves refreshing the explorer tree in case of changing the target framework for a file. In large solutions, updating the tree could take a long time but since changing the target framework occurs rarely in real life, we can live with that delay without anyone noticing.
After fixing another issue, we accidentally started sending “changing the target framework” event on every opening of a text control. Since any “Navigate to” action opens a text control, the To-Do Explorer tree started refreshing itself way too often.
To fix the issue, we stopped sending redundant events, and only fire them if there is an explicit target framework change.
Performance issues fixed in ReSharper 2018.1.1
The latest updates of ReSharper and Rider (version 2018.1.1) come with additional performance fixes. We did a review of all of our components that call into Visual Studio during startup, and optimized them by either postponing these calls until needed.
Unfortunately, we did introduce a regression in typing speed, a bugfix release will be made available in the very near future.
Other than that, here’s an overview of a few noteworthy changes:
RSRP-469057 – Investigate JsonSchemaCache that takes 800 MB
Caching JSON schemas in memory can be killer… Profiling a repro project, we noticed lots of JSON schema-related string duplicates – essentially wasting precious memory.
As it turns out, the JSON schema cache was not shared between projects! This has been updated, reducing memory usage for solutions that contain many projects using JSON.
RSRP-452954 – Postpone calling VsFontsManager.UpdateFonts until editor is open
During startup, ReSharper called into Visual Studio’s VsFontsManager.UpdateFonts() to get information about available and configured fonts. Turns out this method is not extremely fast (and who knows, being on the execution stack might even cause the yellow unresponsiveness banner to point at ReSharper)
Since ReSharper does not need this information during startup, we now lazily request this information from Visual Studio when needed. And since this will always be after Visual Studio itself initializes its editor package which provides font information, ReSharper can get font information much faster.
RSRP-457956 – VsKeyBindingsProcessor might be slow
ReSharper used to contain a component that monitored usage of key bindings, to help determine whether commands were called using a keyboard shortcut or by other means (such as a menu item or toolbar button).
When requesting key binding information from Visual Studio, ReSharper would have to wait for several VSPackages to be loaded. We have now removed this component and are using a less invasive technique to determine how a command was invoked, improving startup speed.
RSRP-469272 Rename: .cshtml files get processed during rename of private field in .cs file.
This problem was introduced several releases ago when we added Tag Helpers support into Razor. As part of that support, ReSharper started looking for C# code entities in Razor files, despite the visibility modifier of a code entity. As a result, Find Usages looked in Razor files even for private members while gathering files for the Rename refactoring.
Now, we take the visibility modifier into account, and this dramatically narrows down a file’s scope for further searching.
RSRP-469293 [Performance Report] Open ReSharper main menu RSRP-469353 [Performance Report] Typing some code is very slow
The availability of any ReSharper refactoring depends on the cursor position. To calculate the availability for some of them, ReSharper gathers lots of information from different places. In these issues, ReSharper asks our internal database (levelDB) whether a file has language injections or not. Since levelDB is hosted on disk, this triggers lots of I/O operations which can sometimes be slow. This issue was introduced some time ago when we refactored our codebase in order to reduce memory traffic.
To fix these issues, we’ve added a cache for injected languages which decreases the number of I/O operations.
Conclusion
This marks the end of our series around ReSharper performance improvements that will benefit both ReSharper and Rider. We discussed a number of high-level, architectural changes that will start surfacing with the next releases of ReSharper and Rider. We also looked at specific performance fixes that were made in ReSharper 2018.1 and 2018.1.1.
We are going to make it a habit to publish blog posts about performance improvements we are making in future ReSharper release cycles. Keep an eye on our blog and Twitter!
These updates are here to deliver the hotfix for the Zip Slip vulnerability, which was found in several third-party tools used both by ReSharper Ultimate and Rider. Here is a summary of the changes we’ve made in our codebase to prevent such issues:
Rider has been updated: added checks for path traversal.
DotNetZip has been updated to version 1.11.0, which already has the fix.
SharpZipLib has been updated to include checks for path traversal.
In addition, ReSharper 2018.1.3 fixes TLS web exception, which could be thrown while looking for updates via ReSharper | Help | Check for updates in case of invalid custom IE proxy settings on a machine.
If you’re a long-term dotMemory user, you may have noticed the absence of big new features in dotMemory ever since we added support for memory dumps in 2017.2. Rest assured this is not because we’ve lost interest in memory profiling. The opposite is true: our team has been investing even more effort in this area, but most of the current changes are happening under the profiler’s hood.
One such changes is the way dotMemory collects and processes data in real time. This may lead to many new features in the future, but as of now, it has led to a couple of neat improvements. Both of them are related to the real-time memory usage diagram (the timeline) that you see during profiling.
First of all, we’ve stopped using Windows performance counters as a data provider and switched to Microsoft Profiling API. As a result, the timeline data are now more precise and do not differ from the data you see in a snapshot. But what is more important, the timeline is now available for all types of apps including .NET Core, ASP.NET Core, IIS-hosted web apps, Windows services, etc.
The “Allocated in LOH” chart
The second improvement is a new chart entitled Allocated in LOH since GC. It probably deserves a more detailed explanation.
A brief reminder on what LOH is and why is it important: Large Object Heap (or LOH for short) is a separate segment of the managed heap used to store large objects. When an object is larger than 85 KB, CLR doesn’t allocate it to the Gen 0 Heap, but to the LOH instead.
For the sake of performance, LOH is never compacted (though you can force the garbage collector to compact LOH in .NET Framework 4.5.1 and later). As a result, LOH becomes fragmented over time. Another problem is that CLR collects unused objects from LOH only during full garbage collections. Thus, LOH objects can take space even if they are no longer used. All this leads to your app having a larger memory footprint (on x86 systems this may even result in OOM exceptions).
Image may be NSFW. Clik here to view.
So, how does the improved timeline help you control LOH? In 2018.2, it shows you not only the size of LOH, but all allocations to LOH instantly as they happen. This helps understand when LOH allocations happen (on application startup, during some work, etc.) and how intense they are (e.g. you can have some significant LOH memory traffic that doesn’t change the LOH size).
Image may be NSFW. Clik here to view.
On the GIF above, you see the Allocated in LOH chart (oblique hatching above the LOH size graph) of a simple application that constantly allocates large objects. Note that the chart shows you the size of objects that have been allocated in LOH since the last Garbage Collection. That’s why, after each GC, the graph restarts from zero.
Before you download the latest ReSharper Ultimate EAP and try the feature for yourself, we have one more small reminder about premature optimization. If you don’t see any evident problems with memory consumption, there’s nothing bad about your app allocating memory in LOH. In most cases, you can use the new Allocated in LOH chart simply to get a better understanding of how your app works.
