{"id":34833,"date":"2024-11-01T16:06:51","date_gmt":"2024-11-01T16:06:51","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=34833"},"modified":"2024-11-01T11:09:05","modified_gmt":"2024-11-01T11:09:05","slug":"analyzing-the-performance-of-the-proxy-library","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/analyzing-the-performance-of-the-proxy-library\/","title":{"rendered":"Analyzing the Performance of the “Proxy” Library"},"content":{"rendered":"

Since the recent announcement of the Proxy 3 library<\/a>, we have received much positive feedback, and there have been numerous inquiries regarding the library’s actual performance. Although the “Proxy” library is designed to be fast<\/strong>, fulfilling one of our six core missions, it is not immediately clear how fast “Proxy” can be across different platforms and scenarios.<\/p>\n

To better understand the performance of the “Proxy” library, we designed 15 benchmarks<\/a>, tested in four different environments, and automated them in our GitHub pipeline<\/a> to generate benchmarking reports for every code change in the future. Everyone can download the reports and raw benchmarking data attached to each build. The rest of this article delves into the benchmarking details. The numbers shown below were generated from a recent CI build<\/a>.<\/p>\n

Indirect Invocation<\/h2>\n

Both proxy<\/code><\/a> objects and virtual functions can perform indirect invocations. However, since they have different semantics and memory layout, it should be interesting to see how they compare to each other.<\/p>\n

Because make_proxy<\/code><\/a> can effectively place a small object alongside metadata (similar to “small buffer optimization” in some other C++ libraries), the benchmarks are divided into two categories: invocation on small objects (4 bytes) and on large objects (48 bytes). By invoking 1,000,000 object of 100 different types, we got the first two rows of the report:<\/p>\n\n\n\n\n\n\n
<\/th>\nMSVC on Windows Server 2022 (x64)<\/th>\nGCC on Ubuntu 24.04 (x64)<\/th>\nClang on Ubuntu 24.04 (x64)<\/th>\nApple Clang on macOS 15 (ARM64)<\/th>\n<\/tr>\n<\/thead>\n
Indirect invocation on small objects via proxy<\/code> vs. virtual functions<\/td>\n\ud83d\udfe2proxy<\/code> is about 261.7% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 44.6% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 71.6% faster<\/strong><\/td>\n\ud83d\udfe1proxy<\/code> is about 4.0% faster<\/strong><\/td>\n<\/tr>\n
Indirect invocation on large objects via proxy<\/code> vs. virtual functions<\/td>\n\ud83d\udfe2proxy<\/code> is about 186.1% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 15.5% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 17.0% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 10.5% faster<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

From the report, proxy<\/code> is faster in all four environments, especially on Windows Server. This result is expected because the implementation of proxy<\/code> directly stores the metadata of the underlying object, making it more cache-friendly.<\/p>\n

Lifetime Management<\/h2>\n

In many applications, lifetime management of various objects can become a performance hotspot compared to indirect invocations. We benchmarked this scenario by creating 600,000 small or large objects within a single std::vector<\/code> (with reserved space).<\/p>\n

Besides proxy<\/code>, there are three typical standard options for storing arbitrary types: std::unique_ptr<\/code>, std::shared_ptr<\/code>, and std::any<\/code>. std::variant<\/code> is not included because it is essentially a tagged union<\/a> and can only provide storage for a known set of types (though useful in data context management).<\/p>\n

For small objects, proxy<\/code> and std::any<\/code> usually won’t allocate additional storage. For large objects, proxy<\/code> and std::shared_ptr<\/code> offer allocator support (via pro::allocate_proxy<\/code><\/a> and std::allocate_shared<\/code><\/a>) to improve performance, while there is no direct API to customize std::unique_ptr<\/code> or std::any<\/code>.<\/p>\n

Here are the types we used in the benchmarks:<\/p>\n\n\n\n\n\n\n\n
Small types<\/th>\nLarge types<\/th>\n<\/tr>\n<\/thead>\n
int<\/code><\/td>\nstd::array<char, 100><\/code><\/td>\n<\/tr>\n
std::shared_ptr<int><\/code><\/td>\nstd::array<std::string, 3><\/code><\/td>\n<\/tr>\n
std::unique_lock<std::mutex><\/code><\/td>\nstd::unique_lock<std::mutex><\/code> + void*[15]<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

By comparing proxy<\/code> with other solutions, we got the following numbers:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
<\/th>\nMSVC on Windows Server 2022 (x64)<\/th>\nGCC on Ubuntu 24.04 (x64)<\/th>\nClang on Ubuntu 24.04 (x64)<\/th>\nApple Clang on macOS 15 (ARM64)<\/th>\n<\/tr>\n<\/thead>\n
Basic lifetime management for small objects with proxy<\/code> vs. std::unique_ptr<\/code><\/td>\n\ud83d\udfe2proxy<\/code> is about 467.0% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 413.0% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 430.1% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 341.1% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for small objects with proxy<\/code> vs. std::shared_ptr<\/code> (without memory pool)<\/td>\n\ud83d\udfe2proxy<\/code> is about 639.2% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 509.3% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 492.5% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 484.2% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for small objects with proxy<\/code> vs. std::shared_ptr<\/code> (with memory pool)<\/td>\n\ud83d\udfe2proxy<\/code> is about 198.4% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 696.1% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 660.0% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 188.5% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for small objects with proxy<\/code> vs. std::any<\/code><\/td>\n\ud83d\udfe2proxy<\/code> is about 55.3% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 311.0% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 323.0% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 18.3% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for large objects with proxy<\/code> (without memory pool) vs. std::unique_ptr<\/code><\/td>\n\ud83d\udfe2proxy<\/code> is about 17.4% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 14.8% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 29.7% faster<\/strong><\/td>\n\ud83d\udd34proxy<\/code> is about 6.3% slower<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for large objects with proxy<\/code> (with memory pool) vs. std::unique_ptr<\/code><\/td>\n\ud83d\udfe2proxy<\/code> is about 283.6% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 109.6% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 204.6% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 88.6% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for large objects with proxy<\/code> vs. std::shared_ptr<\/code> (both without memory pool)<\/td>\n\ud83d\udfe2proxy<\/code> is about 29.2% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 6.4% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 6.5% faster<\/strong><\/td>\n\ud83d\udfe1proxy<\/code> is about 4.8% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for large objects with proxy<\/code> vs. std::shared_ptr<\/code> (both with memory pool)<\/td>\n\ud83d\udfe2proxy<\/code> is about 10.8% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 9.9% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 8.3% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 53.2% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for large objects with proxy<\/code> (without memory pool) vs. std::any<\/code><\/td>\n\ud83d\udfe2proxy<\/code> is about 13.4% faster<\/strong><\/td>\n\ud83d\udfe1proxy<\/code> is about 1.3% slower<\/strong><\/td>\n\ud83d\udfe1proxy<\/code> is about 0.9% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 9.5% faster<\/strong><\/td>\n<\/tr>\n
Basic lifetime management for large objects with proxy<\/code> (with memory pool) vs. std::any<\/code><\/td>\n\ud83d\udfe2proxy<\/code> is about 270.7% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 80.1% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 136.9% faster<\/strong><\/td>\n\ud83d\udfe2proxy<\/code> is about 120.4% faster<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

From the benchmarking results:<\/p>\n