在大型应用中应避免使用STL吗？

这听起来像是一个很奇怪的问题，但是在我的部门中，我们遇到以下问题：

我们正在开发一个服务器应用程序，该应用程序正在变得越来越大，即使是在考虑将其拆分为不同部分（DLL文件）时，也可以在需要时动态加载，然后再卸载，以便能够处理性能问题。

但是：我们正在使用的函数将输入和输出参数作为STL对象传递，并且正如Stack Overflow答案中所述，这是一个非常糟糕的主意。（该帖子包含一些解决方案和技巧，但看起来并不十分牢固。）

显然，我们可以用标准C ++类型替换输入/输出参数，并从函数内部的那些对象创建STL对象，但这可能会导致性能下降。

是否可以得出结论，如果您正在考虑构建一个可能会增长到一台PC无法再处理的应用程序，您绝对不能将STL用作一项技术吗？

有关此问题的更多背景：该问题
似乎有一些误解：问题如下：
我的应用程序正在使用大量性能（CPU，内存）以完成其工作，我想分拆此工作分解为不同的部分（由于程序已经被拆分为多个功能），从我的应用程序中创建一些DLL并将某些功能放入这些DLL的导出表并不难。这将导致以下情况：

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1是安装在Machine1上的应用程序的实例，而App_Inst2是安装在Machine2上的同一应用程序的实例。
DLL1.x是安装在Machine1上的DLL，而DLL2.x是安装在Machine2上的DLL。
DLLx.1涵盖了导出的function1。
DLLx.2涵盖了导出的function2。

现在在Machine1上，我想执行function1和function2。我知道这会使Machine1重载，所以我想向App_Inst2发送一条消息，要求该应用程序实例执行function2。

function1和function2的输入/输出参数是STL（C ++标准类型库）对象，通常，我可能希望客户对App_Inst1，App_Inst2，DLLx.y进行更新（但不是全部，客户都可以升级Machine1，但是而不是Machine2，或者仅升级应用程序，而不升级DLL，反之亦然，...）。显然，如果接口（输入/输出参数）发生变化，则将迫使客户进行完全升级。

但是，如所引用的StackOverflow URL中所述，对App_Inst1或DLL中的一个进行简单的重新编译可能会导致整个系统崩溃，因此，我的原始帖子标题不建议使用STL（C ++标准模板）库）用于大型应用程序。

希望借此我清除一些问题/疑问。

这是一个石冷的经典XY问题。

您真正的问题是性能问题。但是，您的问题清楚地表明，您没有对性能问题的实际来源进行性能分析或其他评估。相反，您希望将代码拆分为DLL可以神奇地解决问题（就记录而言，它不会），现在您担心该非解决方案的一个方面。

相反，您需要解决实际的问题。如果您有多个可执行文件，请检查是哪一个导致速度下降。在使用它时，请确保它实际上是程序占用了所有处理时间，而不是配置错误的以太网驱动程序或类似的东西。然后，开始分析代码中的各种任务。高精度计时器是您的朋友。经典的解决方案是监视一段代码的平均和最坏情况下的处理时间。

掌握数据后，您可以确定如何解决问题，然后可以确定在哪里进行优化。

如果必须在多个物理计算机之间拆分软件，则在计算机之间传递数据时必须具有某种形式的序列化，因为只有在某些情况下，您才可以在计算机之间实际发送相同的二进制文件。大多数序列化方法在处理STL类型时都没有问题，因此这种情况不会令我担心。

如果必须将应用程序拆分为共享库（DLL）（出于性能方面的考虑，在执行此操作之前，您确实应确保它实际上会解决您的性能问题），但传递STL对象可能是一个问题，但并非必须如此。正如您提供的链接已经描述的那样，如果您使用相同的编译器和相同的编译器设置，则传递STL对象将起作用。如果用户提供DLL，则您可能无法轻松依靠它。如果提供所有DLL并一起编译所有内容，那么您也许可以依靠它，并且跨DLL边界使用STL对象的可能性很大。您仍然需要当心编译器设置，以便在传递对象所有权时不会得到多个不同的堆，尽管这不是STL特定的问题。

我们正在处理一个服务器应用程序，该应用程序正在变得越来越大，即使是在考虑将其拆分为不同部分（DLL）的时候，也可以在需要时动态加载，然后再卸载，以便能够处理性能问题

RAM很便宜，因此非活动代码也很便宜。加载和卸载代码（尤其是卸载）是一个脆弱的过程，不太可能对现代台式机/服务器硬件上的程序性能产生重大影响。

缓存更昂贵，但是只会影响最近处于活动状态的代码，而不会影响未使用的内存中的代码。

通常，程序由于数据大小或CPU时间而不是代码大小而超出了他们的计算机。如果您的代码大小太大而导致严重的问题，那么您很可能首先想看看为什么会发生这种情况。

但是：我们正在使用的函数将输入和输出参数作为STL对象传递，并且正如此StackOverflow URL中所述，这是一个非常糟糕的主意。

只要dll和可执行文件都使用相同的编译器构建并针对相同的C ++运行时库动态链接，就可以了。因此，如果将应用程序及其关联的dll作为单个单元构建和部署，那么这应该不是问题。

问题可能出在库是由不同的人构建还是可以分别进行更新的时候。

是否可以得出结论，如果您正在考虑构建一个可能增长到一台PC无法再处理的应用程序，您绝对不能将STL用作一项技术吗？

并不是的。

一旦开始将应用程序分布到多台计算机上，就需要考虑如何在这些计算机之间传递数据的全部注意事项。是否使用STL类型或更多基本类型的详细信息可能会在噪声中丢失。

不，我认为不会得出结论。即使您的程序分布在多台计算机上，也没有理由在内部使用STL强制您在模块间/进程间通信中使用它。

实际上，我认为您应该从一开始就将外部接口的设计与内部实现分开，因为与内部使用的方法相比，前者将更牢固/更难更改

您错过了这个问题的重点。

基本上有两种类型的DLL。你自己的，别人的。“ STL问题”是您和他们可能未使用同一编译器。显然，这对于您自己的DLL而言不是问题。

如果您使用相同的编译器和构建选项同时在同一源树中构建DLL，则它将正常运行。

但是，将应用程序分为多个部分的“ Windows风格”方式是COM组件，其中一些可重复使用。它们可以很小（单个控件或编解码器），也可以很大（IE可以作为ms控件中的COM控件，在mshtml.dll中）。

在需要时动态加载，然后再卸载

对于服务器应用程序，这可能会带来可怕的效率。只有当您的应用程序在很长一段时间内经历多个阶段时，它才真正可行，这样您才知道何时不再需要某些东西。它使我想起使用叠加机制的DOS游戏。

此外，如果您的虚拟内存系统运行正常，它将通过调出未使用的代码页来为您处理。

可能会增长到一台PC无法再处理的程度

购买更大的PC。

不要忘记，通过正确的优化，笔记本电脑可以胜过hadoop集群。

如果您确实需要多个系统，则必须非常仔细地考虑它们之间的边界，因为这是序列化成本所在。在这里，您应该开始研究MPI之类的框架。

我们正在开发一个服务器应用程序，该应用程序正在变得越来越大，即使是在考虑将其拆分为不同部分（DLL文件）时，也可以在需要时动态加载，然后再卸载，以便能够处理性能问题。

第一部分很有意义（出于性能原因，将应用程序拆分到不同的机器上）。

第二部分（加载和卸载库）没有意义，因为这是额外的工作，并且不会（确实）改进。

使用专用的计算机可以更好地解决您所描述的问题，但这些计算机不能与同一（主）应用程序一起使用。

经典解决方案如下所示：

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

在前端计算机和计算机之间，您可能需要执行其他工作，例如负载平衡器和性能监视，并且在专用计算机上保留专门的处理对于缓存和吞吐量优化非常有用。

这绝不意味着额外地加载/卸载DLL，也与STL无关。

也就是说，根据需要在内部使用STL，并在元素之间序列化数据（请参阅grpc和协议缓冲区以及它们解决的问题的类型）。

这就是说，在您提供的信息有限的情况下，这确实像经典的xy问题（如@Graham所说）。