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问题）

1. Put new malloc in lib and make sure to link it first (Other SO-question)

这有一个缺点，例如 strdup仍然会使用旧的malloc和免费的可能会崩溃的程序。

2。使用lib.exe（Chrome）从静态libcrt库中删除malloc

这是测试/使用（？）for chrome / chromium ，但有一个缺点，它只适用于静态链接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?

推荐答案

问：一个C ++程序分割在几个DLL应该：

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对象，类等。你不能通过dll边界的c ++对象，没有很多非常仔细的设计和很多编译器特定的魔法或痛苦从各种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屋！