c++ - 由于调试符号而产生的巨大可执行文件，为什么呢？

Question

我们一直在银行开发大型金融应用程序。最初是15万行非常糟糕的代码。到1个月前，它已经减少到一半多一点，但是可执行文件的大小仍然很大。我期望，因为我们只是使代码更具可读性，但是模板化代码仍在生成大量目标代码，因此我们的工作效率更高。

该应用程序分为大约5个共享对象和一个主对象。更大的共享对象之一是40Mb，即使代码缩小，共享对象也会增加到50Mb。

我对代码开始增长并不感到完全惊讶，因为毕竟我们要添加一些功能。但是令我惊讶的是它增长了20％。当然，没有人接近编写20％的代码，因此，我很难想象它有多大的增长。该模块让我很难分析，但是在星期五，我有了一个新的数据点，这可以为您提供一些启示。

SOAP服务器可能有10个提要。代码是自动生成的，非常糟糕。每个服务都有一个解析器类，其代码完全相同，例如:

#include <boost/shared_ptr.hpp>
#include <xercesstuff...>
class ParserService1 {
public:
  void parse() {
    try {
      Service1ContentHandler*p = new Service1ContentHandler( ... );
      parser->setContentHandler(p);
      parser->parser();
    } catch (SAX ...) {
      ...
    }
  }
};

这些类完全没有必要，只需一个函数即可。每个ContentHandler类都是使用相同的7或8个变量自动生成的，可以与继承共享这些变量。

因此，当我从代码中删除解析器类以及所有类时，我期望代码的大小会减小。但是只有10种服务，我没想到它会从38Mb下降到36Mb。这简直是​​无稽之谈。

我唯一能想到的是，每个解析器都包含boost::shared_ptr，一些Xerces解析器内容，并且某种程度上，编译器和链接器为每个文件重复存储了所有这些符号。我很想知道在任何情况下。

因此，有人可以建议我如何追踪为什么这样的简单修改会产生如此大的影响吗？我可以在模块上使用nm来查看其中的符号，但这将产生大量痛苦的半可读内容。

另外，当一位同事在我的新库中运行她的代码时，用户时间从1m55秒变为1m25秒。实时变化很大，因为我们正在等待速度较慢的SOAP服务器(恕我直言，SOAP是CORBA的极差替代品...)，但是CPU时间相当稳定。我原本希望减少这么多的代码大小会带来一点提升，但是最重要的是，在具有大量内存的服务器上，考虑到我并没有改变它的体系结构，速度真的受到了如此之大的影响，我真的感到惊讶。 XML处理本身。

我将在星期二进行更进一步的介绍，希望能获得更多的信息，但是如果有人对我如何获得如此大的进步有所了解，我很想知道。

更新:
我验证了，实际上，在任务中包含调试符号似乎根本不会改变运行时间。为此，我创建了一个包含很多内容的头文件，其中包括两个在此处起作用的文件:boost共享指针和一些xerces XML解析器。似乎没有影响运行时性能(我检查是因为两个答案之间存在意见分歧)。但是，我还验证了，即使剥离的二进制大小不变，包含头文件也会为每个实例创建调试符号。因此，即使您不使用给定的文件，即使您不使用它，也存在固定数量的对象符号，这些对象在链接时不会折叠在一起，即使它们可能是相同的。

我的代码如下所示:

#include "includetorture.h"
void f1()
{
    f2(); // call the function in the next file
}

我的特定包含文件的大小约为每个源文件100k。大概，如果我包括更多的内容，它将更高。包含的总可执行文件约为600k，而没有大约9k。我验证了增长与包含文件的数量成线性关系，但是无论如何，剥离后的代码大小都是一样的。

显然，我误以为这是性能提升的原因。我想我已经考虑了这一点。即使我没有删除太多代码，我也简化了许多大型xml字符串处理，并大大减少了通过代码的路径，这大概就是原因。

Answer 1

您可以在Linux上使用readelf实用程序，或者在Windows上使用dumpbin来查找exe文件中各种数据使用的确切空间量。但是，我看不出为什么可执行文件的大小使您担心:调试符号在运行时绝对不使用内存!