-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimizing Report Generation Runtime Using fmt Library's fmt::output_file API #3576
Comments
I wasn't able to repro your timings. On macOS with clang the fmt program is ~2x faster: fmt:
printf:
My guess is that you are comparing a debug version of fmt with an optimized version of printf (since it is a part of the system C runtime). The choice of the buffer size is questionable too. It should normally be a multiple of the page size. |
Hi @vi
Hi @vitaut We are using the optimized version of fmt 10.0.0 which was downloaded from Github's FMT repository. |
We don't distribute binaries, optimized or not so you need to check your build commands. |
Likely related to #3674. |
Update
I also ran a small program in c++ for usage of both, system fprintf and fmt::output_file API but still could not see any difference in the runtime using the output_file API
For c++ program using fprintf -
For c++ programme using fmt::output_file API
Output -
Both the files which were populated have the same size -
Greetings,
I want to share a technical exploration I recently undertook in my C++ program aimed at enhancing the efficiency of the programme's runtime.
We were using fprintf to write to a file and sprintf for character conversion.
However, for performance improvement, I integrated the
fmt
library (version 10) into my C++ project. fmt::output_file API in place of fprintf and fmt::format_to API in place of sprintf My attention was particularly drawn to thefmt::output_file
API, which promised a substantial runtime enhancement of 5-9 times compared to the conventionalfprintf
approach. To my intrigue, though, the anticipated performance gain was not readily evident in my runtime measurements.I initiated the file for writing within a separate function using the
fmt::ostream
class along with thefmt::output_file
API. The code snippet appeared as follows:The
out
object created through this approach was subsequently passed by reference to other functions.I introduced a level of configurability to the buffer size by employing an environment variable. The snippet below demonstrates the dynamic adjustment of the buffer size based on the environment variable
BUFFER_SIZE
:This enabled me to fine-tune the buffer size according to the specific needs of my application.
Despite setting up the
fmt::output_file
API and configuring the buffer size with different values ranging from4k to 65k
, I was surprised to find that there were no runtime improvements. Thefmt
library documentation suggested a significant boost, but I encountered a gap between the expected and observed outcomes.Below is an example snippet of how this API was applied in my C++ code.
When used the
fmt::format_to
API and afmt::memory_buffer
of FMT version 10 in place of system sprintf, I could see a gain of 10 mins in my runtime.Below is an example snippet of how this
fmt::format_to
API was applied in my C++ code.So there was improvement in fmt::format_to API only and this result was expected from the output_file API as well.
Perhaps there are subtleties or bottlenecks that I might have overlooked. If any of you have experienced a similar phenomenon or possess an in-depth understanding of the inner workings of the
fmt
library, your expertise would be invaluable.The text was updated successfully, but these errors were encountered: