{"id":386433,"date":"2024-06-29T06:42:00","date_gmt":"2024-06-29T06:42:00","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=386433"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-06-29T06:42:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=386433","title":{"rendered":"Optimization of .NET applications: a big result of small edits<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

\"0852_NETAppsPerf_MinChangesMajorRes\/image1.png\"<\/p>\n

<\/p>\n

Today we’re going to discuss how small optimizations in the right places of the application can improve its performance. Imagine: we remove the creation of an extra iterator in one place, get rid of boxing in the other. As a result, we get drastic improvements because of such small edits.<\/p>\n

<\/a> <\/p>\n

One old and simple idea runs like a golden thread through the article. Please, remember it. <\/p>\n

<\/p>\n

Premature optimizations are evil.<\/p>\n

<\/p>\n

Sometimes it happens that optimization and readability go in slightly different directions. Code may work better, but it is harder to read and maintain. And vice versa \u2014 code is easy to read and modify but has some performance problems. Therefore, it is important to understand what we are willing to sacrifice in such cases.<\/p>\n

<\/p>\n

A developer may read the article, rush to edit a project’s code base and\u2026 get no performance improvements. And code becomes more complex.<\/p>\n

<\/p>\n

That’s why it is important to (always) approach the case with a cool head. It is great if you know your application’s bottlenecks where optimization can help. Otherwise, various profilers are here to the rescue. They can provide a large amount of information about the application. In particular, describe its behavior in dynamics. For example, instances of what types are created the most frequently, how much time the application spends on garbage collection, how long a particular code fragment is executed etc. Two JetBrains tools are worth mentioning: dotTrace<\/a> and dotMemory<\/a>. They are convenient and collect a lot of information. Besides, it is perfectly visualized. JetBrains, you’re cool!<\/p>\n

<\/p>\n

But let’s get back to the optimizations. Throughout the article we’ll analyze several cases that we have faced and that seemed the most interesting. Each of described edits gave positive result, as it was made in the bottlenecks marked by the profilers. Unfortunately, I did not record the results of each change I made, but I’ll show the general optimization result at the end of the article.<\/p>\n

<\/p>\n

Note<\/strong>: This article is about working with .NET Framework. As experience shows (see the example with Enum.GetHashCode<\/a>), sometimes the same C# code fragment may demonstrate a more optimal performance on .NET Core \/ .NET than on .NET Framework.<\/p>\n

<\/p>\n

And what, in fact, are we optimizing?<\/h2>\n

<\/p>\n

The tips, described in the article, are relevant to every .NET application. Again, the edits are the most useful when done in the bottlenecks.<\/p>\n

<\/p>\n

Beware that we are not going to delve into any abstract theoretical reasoning. In this context, the «change the code to avoid the creation of one iterator» type of tips would look bizarre. All the problems listed in this article were identified after I profiled the PVS-Studio static analyzer<\/a> for C#. The main purpose of profiling was to reduce the analysis time.<\/p>\n

<\/p>\n

After the work started, it quickly became clear that the analyzer had serious problems with garbage collection. It took a significant amount of time. In fact, we’d known this before, just made sure of it once again. By the way, earlier we had done several optimizations of the analyzer and we have a separate article<\/a> on that.<\/p>\n

<\/p>\n

However, the problem was still relevant.<\/p>\n

<\/p>\n

Look at the screenshot below (full-size image is here<\/a>). This is the result I got after profiling the PVS-Studio C#. It used 8 threads \u2014 8 lines in the screenshot. The garbage collection clearly took a significant time in each thread.<\/p>\n

<\/p>\n

\"0852_NETAppsPerf_MinChangesMajorRes\/image3.png\"<\/p>\n

<\/p>\n

We rejected «rewrite everything in C» advice and got to work. In particular, we examined the results of the profiling and locally deleted unnecessary extra\/temporary objects. To our luck, this approach immediately showed results.<\/p>\n

<\/p>\n

This is going to be the main topic of the article.<\/p>\n

<\/p>\n

What did we gain? Let’s keep the intrigue until the end of the article.<\/p>\n

<\/p>\n

Calling methods with a params parameter<\/h2>\n

<\/p>\n

Methods with a params<\/em> parameter declared in their signature, can take the following as an argument:<\/p>\n

<\/p>\n