关于C 自动变量效率的大小的实际限制是什么?

如果您担心因初始化功能而返回这样的结构的大小，那么我就不会对该语句（如果不确定，您可以随时测量）。

所有现代编译器都已经在进行RVO和NRVO优化。结果，即使您未通过价值返回，也没有制作副本。编译器已经确定了结果将进入特定的目的地，并将副本放在了目的地。

因此，大小约束并不是真正的问题。

也使用C 11引入了移动语义的概念。因此，您不需要按价值返回，而是通过移动返回。在大多数STD容器中，这只是意味着交换几个指针（不幸的是，这对STD :: Array无济于事），但总的来说，它运行良好。

所以对我来说，这可能是按价值返回的。尽管我可能会在课堂上包裹该结构。这样，如果现实叮咬并且确实花费很多，我可以内部更改课程以补偿而不更改代码。

我不认为您可以通过进行64个字节分配来导致任何碎片化。根据我在32位环境中进行大型应用的经验，由于分裂问题，大于16 MB的分配可能会失败。为了使分配产生分裂，他们应该长期生活。对于服务器代码，这超过几天。在64位中，不可能发生Env碎片。

按值传递参数意味着创建副本。这可能不是有效的。推荐的工作正在使用参考。尺寸没有众所周知的限制。

根据我的经验，我建议使用PC这样的平台：

• 变量的大小小于100个字节 - 按值通过;
• var的大小大于1 kb-使用参考并避免复制;

值是中间是灰色区域，这两个决定都可以。再一次，这些数字没有魔法含义。只是一些合理的参考。

我建议您考虑使用参考而不是堆存。

您是否实际上观察到了性能降级，然后将其追溯到此代码？因为如果这只是一个理论上的问题，那么我建议您实际上以看起来直觉和自然的方式编码内容。

完成此操作并确定了所有的纠结后，您可以运行程序，看看您实现的性能是否可以接受；如果不是，则可以设置优化实际瓶颈，而不是想象的

唐纳德·诺斯（Donald Knuth）说："我们应该忘记效率小的效率，大约97％的时间：早产优化是所有邪恶的根源。"

在堆栈上复制64个字节很便宜。它几乎比分配64个字节便宜。如果您将unique_ptr用于分配在堆上的短期寿命变量，您几乎肯定会失去效率。

如果您只需调用您的功能并立即使用返回值，则很快。只有当您打算通过一系列矩阵返回功能来传播矩阵时，您的效率损失就会显着。分配内存和使用unique_ptr的可行性取决于重新返回数据的次数，而不是取决于数据的实际大小。

使用动态阵列为此是过度的。您不仅要分配64个字节以容纳16个浮子。您正在为数组分配4个内存块，每个存储器块将具有用于堆管理的标题，并且每个C 的数组大小，并且内部内部的内存分配通常会使用比您要求的块大，通常会在块边界上对齐。

然后，您拥有容纳每个数组的结构的开销。例如。每个std ::数组是一个包含指向您对象的指针的类，它的8个字节至少为8个字节（指针为4个，而数组长度为4个。

，您没有参考。矩阵中的每一行可能在内存中彼此之间距离很远。如果他们彼此相邻，他们会在单个缓存线中读取。

您最好只使用：

float matrix[4][4[

如果您需要它面向对象，请将其包装在类中：

class Matrix44 
{
    float matrix[4][4];
}

这将更加高效。