Windows malloc 替换(例如 tcmalloc)和动态 crt 链接 [英] Windows malloc replacement (e.g., tcmalloc) and dynamic crt linking

问题描述

使用多个 DLL 和 QT 的 C++ 程序应配备 malloc 替换(如 tcmalloc) 用于可验证由 Windows malloc 引起的性能问题.对于 linux，没有问题，但是对于 windows，有几种方法，我觉得它们都没有吸引力:

A C++ program that uses several DLLs and QT should be equipped with a malloc replacement (like tcmalloc) for performance problems that can be verified to be caused by Windows malloc. With linux, there is no problem, but with windows, there are several approaches, and I find none of them appealing:

1.将新的 malloc 放入 lib 并确保先链接它 (其他 SO 问题)

这有一个缺点，例如 strdup 仍将使用旧的 malloc，而 free 可能会导致程序崩溃.

This has the disadvantage, that for example strdup will still use the old malloc and a free may crash the program.

2.使用 lib.exe (Chrome) 将 malloc 从静态 libcrt 库中移除

这是针对chrome/chromium<进行测试/使用(?)/a>，但缺点是它只能与静态链接 crt 一起使用.如果一个系统库与 msvcrt 动态链接，则静态链接会出现问题，可能存在 堆分配/解除分配不匹配.如果我理解正确，tcmalloc 可以动态链接，这样所有自编译的 dll 都有一个公共堆(这很好).

This is tested/used(?) for chrome/chromium, but has the disadvantage that it just works with static linking the crt. Static linking has the problem if one system library is linked dynamically against msvcrt there may be mismatches in the heap allocation/deallocation. If I understand it correctly, tcmalloc could be linked dynamically such that there is a common heap for all self-compiled dlls (which is good).

3.补丁 crt-源代码 (firefox)

Firefox 的 jemalloc 显然是补丁windows CRT 源代码并构建一个新的 crt.这又是上面的静态/动态链接问题.

Firefox's jemalloc apparently patches the windows CRT source code and builds a new crt. This has again the static/dynamic linking problem above.

可以考虑使用它来生成动态 MSVCRT，但我认为这是不可能的，因为许可证禁止提供具有相同名称的修补 MSVCRT.

One could think of using this to generate a dynamic MSVCRT, but I think this is not possible, because the license forbids providing a patched MSVCRT with the same name.

4.在运行时动态修补加载的 CRT

一些商业内存分配器可以做这样的魔术.tcmalloc 也可以，但这看起来相当难看.它有一些问题，但它们已被修复.目前，使用 tcmalloc 它不能在 64 位窗口下工作.

Some commercial memory allocators can do such magic. tcmalloc can do, too, but this seems rather ugly. It had some issues, but they have been fixed. Currently, with tcmalloc it does not work under 64 bit windows.

有更好的方法吗?有什么意见吗?

Are there better approaches? Any comments?

推荐答案

问:一个跨多个 dll 拆分的 C++ 程序应该:

Q: A C++ program that is split accross several dlls should:

A) 替换 malloc?

A) replace malloc?

B) 确保分配和取消分配发生在同一个 dll 模块中?

B) ensure that allocation and de-allocation happens in the same dll module?

A:正确答案是 B.一个包含多个 DLL 的 c++ 应用程序设计应该确保存在一种机制来确保在一个 dll 中的堆上分配的东西被同一个 dll 模块释放.

A: The correct answer is B. A c++ application design that incorporates multiple DLLs SHOULD ensure that a mechanism exists to ensure that things that are allocated on the heap in one dll, are free'd by the same dll module.

你为什么要把一个 C++ 程序分成几个 dll 呢?通过 C++ 程序，我的意思是你正在处理的对象和类型是 C++ 模板、STL 对象、类等.你不能在没有大量非常仔细的设计和大量编译器特定魔法的情况下传递 C++ 对象跨越 dll 边界，或者痛苦来自各种 dll 中大量重复的目标代码，因此应用程序对版本非常敏感.对类定义的任何微小更改都将强制重新构建所有 exe 和 dll，至少会消除 dll 方法在应用开发中的主要优势之一.

Why would you split a c++ program into several dlls anyway? By c++ program I mean that the objects and types you are dealing with are c++ templates, STL objects, classes etc. You CAN'T pass c++ objects accross dll boundries without either lot of very careful design and lots of compiler specific magic, or suffering from massive duplication of object code in the various dlls, and as a result an application that is extremely version sensitive. Any small change to a class definition will force a rebuild of all exe's and dll's, removing at least one of the major benefits of a dll approach to app development.

要么坚持应用程序和 dll 之间的直接 C 接口，要么受苦，要么只是将整个 C++ 应用程序编译为一个 exe.

Either stick to a straight C interface between app and dll's, suffer hell, or just compile the entire c++ app as one exe.

这篇关于Windows malloc 替换(例如 tcmalloc)和动态 crt 链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！