profiling

Hello everyone, Welcome to the early access program of our third release of the year, Rider 2020.3. The highlights of the first EAP build include more advanced C# 9 support, new debugger features, and UX improvements. Let’s look into the details. UX improvements The most obvious update is the redesigned Welcome screen. More is less: we’ve tried to make the first window you see in Rider a

Version 2020.2 EAP01 finally brings dotMemory to Linux and macOS! For these systems, dotMemory is currently available only as a command-line tool. The tool is free and lets you take and save memory snapshots. To analyze the snapshots, you still need the standalone version of dotMemory, which is only available on Windows. What you can profile Here's the dotMemory compatibility list for Linux and

It seems that a common problem among profiling tools (including ours) is that they require too much effort from a developer. Profiling currently is seen as some kind of a last resort for when something has gone horribly wrong. The use of profilers is very episodic and chaotic, and it's quite often ineffective because you simply can't be an expert in a tool you use only once every six months. We fi

A little over a year ago, we ran a series of blog posts describing performance improvements we were making to ReSharper. We’ve delivered a lot of improvements in the releases since then, but we haven’t yet delivered on the big one - running ReSharper out of process. We thought it was about time we gave you an update on where we are. TL;DR: This isn’t an announcement post. We don’t have an ETA to

Back in Rider 2018.3, we added a performance profiler to Rider. As we try to deliver new features as quickly as possible, the integrated profiler had some limitations: it only supported the profiling of .NET Framework and .NET Core applications on Windows. Now, it's time to fill the gap. In Rider 2019.1, the profiler gets support for Mono and Mono Unity - and not just on Windows but on macOS and L

This year we’ve focused on two areas to enhance CLion. The first is better C++ language support and general IDE performance improvements. As a result, we’ve added a clangd-based experimental complementary language engine, and a massive amount of work was done which, although invisible at first glance, has helped eliminate dozens of UI freezes in the editor. The second area is the endless world

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

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. In this series: Introducing the ReSharper performance series Taking ReSharper out

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