您的位置:首页 > 软件教程 > 教程 > 内存优化:Boxing

内存优化:Boxing

来源:好特整理 | 时间:2024-06-06 18:49:15 | 阅读:72 |  标签: XING in   | 分享到:

dotMemory 如今,许多开发人员都熟悉性能分析的工作流程:在分析器下运行应用程序,测量方法的执行时间,识别占用时间较多的方法,并致力于优化它们。然而,这种情况并没有涵盖到一个重要的性能指标:应用程序多次GC所分配的时间。当然,你可以评估GC所需的总时间,但是它从哪里来,如何减少呢? “普通”性

dotMemory

如今,许多开发人员都熟悉性能分析的工作流程:在分析器下运行应用程序,测量方法的执行时间,识别占用时间较多的方法,并致力于优化它们。然而,这种情况并没有涵盖到一个重要的性能指标:应用程序多次GC所分配的时间。当然,你可以评估GC所需的总时间,但是它从哪里来,如何减少呢? “普通”性能分析不会给你任何线索。

垃圾收集总是由高内存流量引起的:分配的内存越多,需要收集的内存就越多。众所周知,内存流量优化应该在内存分析器的帮助下完成。它允许你确定对象是如何分配和收集的,以及这些分配背后保留了哪些方法。理论上看起来很简单,对吧?然而,在实践中,许多开发人员最终都会这样说:“好吧,我的应用程序中的一些流量是由一些系统类生成的,这些系统类的名称是我一生中第一次看到的。我想这可能是因为一些糟糕的代码设计。现在我该怎么做?”

这就是这篇文章的主题。实际上,这将是一系列文章,我将在其中分享我的内存流量分析经验:我认为什么是“糟糕的代码设计”,如何在内存中找到其踪迹,当然还有我认为的最佳实践。

简单的例子:如果您在堆中看到值类型的对象,那么装箱肯定是罪魁祸首。装箱总是意味着额外的内存分配,因此移除它很可能会让您的应用程序变得更好。

该系列的第一篇文章将重点关注装箱。如果检测到“bad memory pattern”,该去哪里查找以及如何采取行动?

本系列中描述的最佳实践使我们能够将 .NET 产品中某些算法的性能提高 20%-50%。

您需要什么工具

在我们进一步讨论之前,先看看我们需要的工具。我们在 JetBrains 使用的工具列表非常简短:

  • dotMemory 内存分析器。无论您试图查找什么问题,分析算法始终相同:
    • 在启用内存流量收集的情况下开始分析您的应用程序。
    • 在您感兴趣的方法或功能完成工作后收集内存快照。
    • 打开快照并选择内存流量视图。
  • Heap Allocations Viewer插件。该插件会突出显示代码中分配内存的所有位置。这不是必须的,但它使编码更加方便,并且在某种意义上“迫使”您避免过度分配。

Boxing

装箱是将值类型转换为引用类型。 例如:

int i = 5;
object o = i; // 发生装箱

为什么这是个问题?值类型存储在栈中,而引用类型存储在托管堆中。因此,要将整数值分配给对象,CLR 必须从栈中取出该值并将其复制到堆中。当然,这种移动会影响应用程序的性能。

一个对象的至少占用3个指针单元:对象头(object header)、方法表指针(method table ref)、预留单元(首字段地址/数组长度)

在x64系统3个指针单元意味24字节的开销,而一个int类型本身只占用4字节,其次,栈内存的由执行线程方法栈管理,方法内声明的local变量、字面量更是能够在IL编译期就预算出栈容量,效率远高于运行时堆内存GC体系

如何发现

使用 dotMemory,找到boxing是一项基本任务:

  1. 打开View memory allocations视图。
  2. 查找值类型的对象(Group by Types),这些都是boxing的结果。
  3. 确定分配这些对象并生成大部分流量的方法。

当我们尝试将值类型赋值给引用类型时,Heap Allocation Viewer插件也会提示闭包分配的事实:

? Boxing allocation: conversion from value type 'int' to reference type 'object'

从性能角度来看,您更感兴趣的是这种闭包发生的频率。例如,如果带有装箱分配的代码只被调用一次,那么优化它不会有太大帮助。考虑到这一点,dotMemory 在检测闭包是否引起真正问题方面要可靠得多。

如何修复

在解决装箱问题之前,请确保它确实会产生大量流量。如果是这样,你的任务就很明确:重写代码以消除装箱。当你引入某些值类型时,请确保不会在代码中的任何位置将值类型转换为引用类型。例如,一个常见的错误是将值类型的变量传递给使用字符串的方法(例如 String.Format ):

int i = 5;
string.Format("i = {0}", i); // 引发box

一个简单的修复方法是调用恰当的值类型 ToString() 方法:

int i = 5;
string.Format("i = {0}", i.ToString());

Resize Collections

动态大小的集合(例如 Dictionary , List , HashSet , 和 StringBuilder )具有以下特性: 当集合大小超过当前边界时,.NET 会调整集合的大小并在内存中重新定义整个集合。显然,如果这种情况频繁发生,应用程序的性能将会受到影响。

如何发现

使用 dotMemory 比对两个快照

  1. 打开View memory allocations视图

  2. 找到产生大内存流量的集合类型

  3. 看看是否与 Dictionary<>.Resize List<>.SetCapacity StringBuilder.ExpandByABlock 等等集合扩容有关

内存优化:Boxing

如何修复

如果“resize”方法造成的流量很大,唯一的解决方案是减少需要调整大小的情况数量。尝试预测所需的大小并用该大小初始化集合。

var list = new List(1000); // 初始容量1000

此外请记住,任何大于或等于 85,000 字节的分配都会在大对象堆 (LOH) 上进行。在 LOH 中分配内存会带来一些性能损失:由于 LOH 未压缩,因此在分配时需要 CLR 和空闲列表之间进行一些额外的交互。然而,在某些情况下,在 LOH 中分配对象是有意义的,例如,在必须承受应用程序的整个生命周期的大型集合(例如缓存)的情况下。

Enumerating Collections

使用动态集合时,请注意枚举它们的方式。这里典型的主要头痛是使用 foreach 枚举一个集合,只知道它实现了 IEnumerable 接口。考虑以下示例:

class EnumerableTest
{
	private void Foo(IEnumerable sList)
    {
		foreach (var s in sList)
        {
            
		}
	}
	public void Goo()
    {
		var list = new List();
		for (int i = 0; i < 1000; i++)
        {
			Foo(list);
		}
    }
}

Foo 方法中的列表被转换为 IEnumerable 接口,这意味着枚举器的进一步装箱,因为 List.Enumerator 是结构体。

public struct Enumerator : IEnumerator, IEnumerator, IDisposable
{
    public T Current { get; }

    object IEnumerator.Current { get; }

    public void Dispose();

    public bool MoveNext();

    void IEnumerator.Reset();
}

如何发现

  1. 打开View memory allocations视图
  2. 找到值类型 System.Collections.Generic.List+Enumerator 并检查生成的流量。
  3. 查找生成这些对象的方法。
  4. Heap Allocation Viewer插件也会提示您有关隐藏分配的信息:

内存优化:Boxing

如何修复

避免将集合强制转换为接口。在上面的示例中,最佳解决方案是创建一个接受 List 集合的 Foo 方法重载。

private void Foo(List sList)
{
    foreach (var s in sList)
    {
        
    }
}

如果我们在修复后分析代码,会发现 Foo 方法不再创建枚举器。

don’t prematurely optimize

易读性应该在多数时候成为我们编码的第一原则,而非的性能优先或内存优先。本文讨论的一切都是微观优化,定期进行内存分析是良好的习惯

例如,交换a和b,从第一直觉上我们会编写出以下代码:

int a = 5;
int b = 10;

var temp = a;
a = b;
b = temp;

// 在c# 7+我们甚至可以用元组,进一步增强可阅读性
(a, b) = (b, a);

但是下面这种写法通过按位运算,可以不必申请额外空间来存储temp

a = a ^ b;
b = a ^ b;
a = a ^ b;

但这并不是我们鼓励的:过早的在编码初期进行优化,丧失可读性。在99%的情况下,我们的代码应该只依赖语义,剩下的,交给探查器!

上文Boxing提到的 string.Format 案例,只能代表今天,而不是明天。也许下一个将在IL编译时甚至JIT中去解决值类型装箱问题,Enumerating Collections也是同一个道理。

int i = 5;
string.Format("i = {0}", i); // 引发box

DefaultInterpolatedStringHandler

.net6引入的ref结构 DefaultInterpolatedStringHandler ,就是一个很好的案例

$"..." 这种字符串插值(String Interpolation)语法是在 C# 6.0 中引入的。

var i = 5;
var str = $"i = {i}"; // box

在.net6之前,上面的写法会发生装箱,生成的IL如下:

IL_001a: ldarg.0      // this
IL_001b: ldstr        "i = {0}"
IL_0020: ldarg.0      // this
IL_0021: ldfld        int32 Fake.EventBus.RabbitMQ.RabbitMqEventBus/'d__19'::'5__1'
IL_0026: box          [netstandard]System.Int32
IL_002b: call         string [netstandard]System.String::Format(string, object)
IL_0030: stfld        string Fake.EventBus.RabbitMQ.RabbitMqEventBus/'d__19'::'5__2'

而从.net6开始,生成的IL发生了变化,由原来调用的 System.String::Format(string, object) ,变成了 DefaultInterpolatedStringHandler ,装箱也不见了,内部细节感兴趣的自己去阅读源码,内部用到了高性能的Span,unsafe和ArrayPool

IL_0014: ldloca.s     V_3
IL_0016: ldc.i4.4
IL_0017: ldc.i4.1
IL_0018: call         instance void [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::.ctor(int32, int32)
IL_001d: ldloca.s     V_3
IL_001f: ldstr        "i = "
IL_0024: call         instance void [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::AppendLiteral(string)
IL_0029: nop
IL_002a: ldloca.s     V_3
IL_002c: ldloc.0      // i
IL_002d: call         instance void [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::AppendFormatted(!!0/*int32*/)
IL_0032: nop
IL_0033: ldloca.s     V_3
IL_0035: call         instance string [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::ToStringAndClear()
IL_003a: stloc.1      // str

不要过早优化

不要过早优化!!!

不要过早优化!!!

不要过早优化!!!

Link

本系列参考jetbrains官方团队的博客: https://blog.jetbrains.com/dotnet,加以作者的个人理解做出的二次创作,如有侵权请联系删除:2357729423@qq.com。

小编推荐阅读

好特网发布此文仅为传递信息,不代表好特网认同期限观点或证实其描述。

相关视频攻略

更多

扫二维码进入好特网手机版本!

扫二维码进入好特网微信公众号!

本站所有软件,都由网友上传,如有侵犯你的版权,请发邮件admin@haote.com

湘ICP备2022002427号-10 湘公网安备:43070202000427号© 2013~2024 haote.com 好特网