c++ - 目标文件在 Linux 上比在 macOS 或 Windows 上大 2.5 倍

Question

我有一个文件，当编译成目标文件时，它的大小如下:

• 在 Windows 上，使用 MSVC，它是 8MB。
• 在 macOS 上，使用 clang，它是 8MB。
• 在 Linux(Ubuntu 18.04 或 Gentoo)上，使用 gcc 或 clang，它是 20MB。

该文件(详见下文)是 unicode 表(的一部分)以及字符属性的表示。编码为utf8。

我想到问题可能是 libstdc++ 不能很好地处理文件，所以我在 Gentoo 上用 clang 尝试了 libc++，但它没有做任何事情(目标文件大小保持不变)。

然后我认为这可能是一些优化做了一些奇怪的事情，但是当我从 -O3 开始时，我再次没有尺寸改进。至 -O0 .

The file , 关于 line 50包括 UnicodeTable.inc . UnicodeTable.inc包含 std::array的 unicode 代码点。

我尝试更改 std::array为 C 样式数组，但同样，目标文件大小没有改变。

我有 CodePoint.cpp 的预处理版本可以用 $CC -xc++ CodePoint.i -c -o CodePoint.o 编译. CodePoint.i包含约40k行STL代码和约130k行unicode表。

我尝试上传预处理后的 CodePoint.i到 gists.github.com 和 paste.pound-python.org，但都拒绝了 170k 行的长文件。

在这一点上，我没有想法，非常感谢任何有关找出“臃肿”目标文件大小来源的帮助。

Answer 1

从您链接的 size 的输出中，您可以看到 elf 对象(部分 .rela.dyn)中有 12 MB 的重定位。如果 64 bit relocation占用 24 个字节，您有 132624 个表条目，每个表条目有 4 个指向字符串的指针，这几乎可以解释 12 MB 的差异 (132624 *4 * 24 = 12731904 ~ 12 MB)。

显然，其他格式要么使用更高效的重定位类型，要么直接链接引用，然后将整个 block 与字符串一起重定位为一 block 内存。

由于您将其链接到共享库，因此动态重定位不会消失。

我不确定您当前使用的代码是否可以避免这种情况。但是，我认为 unicode 代码点必须具有最大大小。为什么不按值将代码点存储在 RawCodePoint 结构的 char 数组中？每个代码点字符串的大小不应大于您当前存储的指针，并且表查找的引用局部性实际上可能会有所改善。

constexpr size_t MAX_CP_SIZE = 4; // Check if that is correct

struct RawCodePointLocal {
  const std::array<char, MAX_CP_SIZE> original;
  const std::array<char, MAX_CP_SIZE> normal;
  const std::array<char, MAX_CP_SIZE> folded_case;
  const std::array<char, MAX_CP_SIZE> swapped_case;
  bool is_letter;
  bool is_punctuation;
  bool is_uppercase;
  uint8_t break_property;
  uint8_t combining_class;
};

这样您就不需要为条目重定位。