我正在玩zlib并拥有（简化）代码：
#include <cstring> // memset
#include <string>
#include <zlib.h>
#include <cstdio>
const int compressionLevel_ = 9;
const size_t BUFFER_SIZE = 1024 * 8;
char buffer_[BUFFER_SIZE];
std::string compress(const char *data, size_t const size){
z_stream zs;
memset(&zs, 0, sizeof(zs));
if (deflateInit(&zs, compressionLevel_) != Z_OK)
return {};
zs.next_in = reinterpret_cast<Bytef *>( const_cast<char *>( data ) );
zs.avail_in = static_cast<uInt>( size );
std::string out;
int result;
do {
zs.next_out = reinterpret_cast<Bytef *>(buffer_);
zs.avail_out = BUFFER_SIZE;
result = deflate(&zs, Z_FINISH);
if (out.size() < zs.total_out){
// COMMENT / UNCOMMENT HERE !!!
out.append(buffer_, zs.total_out - out.size() );
}
} while (result == Z_OK);
deflateEnd(&zs);
if (result != Z_STREAM_END)
return {};
return out;
}
int main(){
const char *original = "Hello World";
size_t const original_size = strlen(original);
for(size_t i = 0; i < 1000000; ++i){
const auto cdata = compress(original, original_size);
}
}
实际代码有点大，因为它解压缩并检查解压缩字符串与原始字符串。
如果我用clang或gcc编译，一切都会执行约5秒。
然而......如果我评论这一行：
if (out.size() < zs.total_out){
// COMMENT / UNCOMMENT HERE !!!
// out.append(buffer_, zs.total_out - out.size() );
}
执行需要30秒!!!
如果我试用快速Linux服务器，时间分别为3秒vs 18秒。
我在MacOS上用clang尝试了相同的操作，并且在时间上没有太大的区别。
我尝试了不同级别的优化并且结果仍然存在 - 如果您发表评论，您的执行时间会增加约10倍。
可能是什么原因？
更新
我用gcc尝试了Cygwin - 那里的时间没有区别。
我厌倦了使用gcc的Linux Arm CPU - 25秒vs 2:20 min。
答案 0 :(得分：6)
如果你使用time运行它，你可以注意到一个有趣的事情，如果没有注释，你会得到这样的结果：
$ time ./main
real 0m5.309s
user 0m5.304s
sys 0m0.004s
没有什么特别的，只是在用户空间花了大约5秒，正如预期的那样。但是对于线条评论你突然得到了这个：
$ time ./main
real 0m29.061s
user 0m7.424s
sys 0m21.660s
所以这并不是说你的代码突然变慢了六倍，它实际上在内核中花了5000多倍，这是不寻常的，因为程序只是按其性质计算事物，没有I / O或类似的东西制成。
oprofile证明了这一点，好的一个证明了这一点：
samples % image name symbol name
62451 45.2376 libz.so.1.2.8 /lib64/libz.so.1.2.8
61905 44.8421 libc-2.19.so memset
2752 1.9935 libc-2.19.so _int_free
2549 1.8464 libc-2.19.so _int_malloc
2474 1.7921 libc-2.19.so malloc_consolidate
2263 1.6392 no-vmlinux /no-vmlinux
1365 0.9888 libc-2.19.so malloc
723 0.5237 libc-2.19.so __memcpy_sse2_unaligned
711 0.5150 libstdc++.so.6.0.21 /usr/lib64/libstdc++.so.6.0.21
478 0.3462 libc-2.19.so free
366 0.2651 main main
6 0.0043 ld-2.19.so _dl_lookup_symbol_x
2 0.0014 ld-2.19.so _dl_relocate_object
2 0.0014 ld-2.19.so do_lookup_x
1 7.2e-04 ld-2.19.so _dl_name_match_p
1 7.2e-04 ld-2.19.so check_match.9478
1 7.2e-04 ld-2.19.so strcmp
1 7.2e-04 libc-2.19.so _dl_addr
虽然坏的是这样的：
samples % image name symbol name
594605 74.6032 no-vmlinux /no-vmlinux
102981 12.9207 libc-2.19.so memset
72822 9.1368 libz.so.1.2.8 /lib64/libz.so.1.2.8
9093 1.1409 libc-2.19.so _int_malloc
3987 0.5002 libc-2.19.so sysmalloc
3365 0.4222 libc-2.19.so _int_free
2119 0.2659 libc-2.19.so brk
1958 0.2457 libc-2.19.so systrim.isra.1
1597 0.2004 libc-2.19.so free
1217 0.1527 libc-2.19.so malloc
1123 0.1409 libc-2.19.so sbrk
786 0.0986 libc-2.19.so __memcpy_sse2_unaligned
688 0.0863 libc-2.19.so __default_morecore
669 0.0839 main main
5 6.3e-04 ld-2.19.so _dl_relocate_object
4 5.0e-04 ld-2.19.so do_lookup_x
2 2.5e-04 ld-2.19.so strcmp
1 1.3e-04 ld-2.19.so _dl_lookup_symbol_x
1 1.3e-04 libc-2.19.so _dl_addr
如果你同时从两个二进制文件中查看strace，那么好的只会有64个系统调用（至少在我的系统上），而坏的则会产生4000063个系统调用，其中大部分都是这样的：
brk(0x6c0000) = 0x6c0000
brk(0x6e2000) = 0x6e2000
brk(0x6d2000) = 0x6d2000
brk(0x6c2000) = 0x6c2000
brk(0x6c0000) = 0x6c0000
brk(0x6e2000) = 0x6e2000
brk(0x6d2000) = 0x6d2000
brk(0x6c2000) = 0x6c2000
brk(0x6c0000) = 0x6c0000
所以，我们这里有内存分配 - 释放循环。我们在这里使用动态内存分配/释放的唯一方法就是输出字符串，实际上，如果你将魔术字符串取消注释，但是初始化字符串如std::string out = "1";，你会获得与追加相同的“好”结果字符串。
这必须是分配逻辑中的一些例子，其中你的usage-unusage模式触发glibc首先分配一些内存（一个小块，因此通过brk()），然后将其释放回系统。使用初始化（静态或附加）字符串，您将拥有不同的使用模式，并且glibc无法将内存返回给系统。如果强制glibc没有返回任何内存（参见man mallopt），那么即使使用“bad”（注释）二进制文件，结果也是一样的：
$ time MALLOC_TRIM_THRESHOLD_=-1 ./main
real 0m5.094s
user 0m5.096s
sys 0m0.000s