msvcrt dll

我目前正在将一种实验性语言移植到Windows。这种实验性语言是用LLVM用C++构建的，并且严重依赖GCC扩展，如VLA和CompoundStatementExpressions，这基本上使得用MSVC构建是不可能的（尽管我有一个真正可怕的想法，我可能会在以后尝试）。幸运的是，您现在可以使用Clang在Windows上构建东西，这解决了很多问题。但是，clang-cl只需编译代码-它仍然使用MicrosoftC++标头和指向MicrosoftC++运行时的链接。这是一件好事，因为它确保了与win32API和其他Windows可执行文件的最大兼容性。不幸的是，这也意味着你malloc()从MSVCRT获得了Windows实现（具体来说，它与VisualStudio附带的CRT静态链接），这很可能是C历史上编译过的最糟糕的一堆烂垃圾之一。我学会了如何像许多人一样，通过独立游戏开发进行编程。像许多人一样，我从未发布过一款游戏，但我确实编写了一堆代码，这些代码现在被遗忘在丢失的GitHub存储库中。我被教导分配内存就是召唤死亡本身来破坏你的表现。一次调用malloc()在任何帧期间都可能使您的游戏无法玩。任何需要以任何规律发生的分配都需要编写一个定制的、专门构建的分配器，通常是使用空闲列表的固定大小的块分配器，或者是在关卡结束后释放的贪婪分配器。通过使用线程本地存储可以进行更多优化，以维护特定于线程的分配器，而无需在并发上浪费时间。事实证明，在Linux上您实际上不需要任何这些。您基本上malloc()可以随心所欲（在合理范围内），而且速度会非常快。LLVM是为Linux构建的——或者更确切地说，它是为MacOSX构建的，它兼容POSIX，如果你眯着眼睛看起来就像一个Linux系统。大多数优化旨在使其在Mac或Linux上运行得更快。由于它是一个编译器，它会进行很多微小的分配，因为它基本上将控制流表示为一个巨大的有向图。我实际上认为它使用自定义分配器来分配这些小节点，因为这就是我会做的，但实际上，它只是new在任何地方调用并让Linuxmalloc()实现处理它。我关心的原因是因为我正在研究的这种实验性语言在启动时需要JIT其核心库-在Linux上执行此操作大约需要1.1秒，在Windows上需要31秒。起初，我认为这种低效率来自这种std::unordered_map到处使用的实验性语言，因为这会为每个项目分配一个新的内存块以确保迭代器的稳定性，并且与基本上任何其他哈希实现相比，它的效率非常低是众所周知的。我将其替换为Google的Abseilflat_hash_map实现，并在Windows上实现了令人印象深刻的2倍加速，将启动时间降至16秒。相当不错，符合我的预期。你能猜出相应的Linux加速是多少吗？