gpt4 book ai didi

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

转载 作者:可可西里 更新时间:2023-11-01 11:43:54 26 4
gpt4 key购买 nike

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

  • 在 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 行的长文件。

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

最佳答案

从您链接的 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;
};

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

关于c++ - 目标文件在 Linux 上比在 macOS 或 Windows 上大 2.5 倍,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51064431/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com