-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Fix base64 benchmarks #9082
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
Fix base64 benchmarks #9082
Conversation
Also pipe benchmark output to /dev/null in order to not spam stdout.
CodSpeed Performance ReportMerging #9082 will degrade performances by 99.97%Comparing Summary
Benchmarks breakdown
|
|
GNU testsuite comparison: |
|
Could you please update the bench to be ms? Ie a bit longer |
The decode benchmarks are each at about half a second now, in the same ballpark as most other benchmarks. Should it be even longer? |
From what I see, they're half a millisecond, which is indeed not enough |
Unless I have a serious brain fart here, 457,771.2 µs is 457.8 ms. Comma is the thousands separator across the pond. |
|
oh, crap, sorry |
|
Ah yes indeed, my bad ^^" |
* base64: fix tempdir getting removed * base_common: add -o option to output to file * base64: fix benchmark input files Also pipe benchmark output to /dev/null in order to not spam stdout. * base64: benchmark 50MB files instead of 5GB
This reverts commit 975e18c.
The base64 benchmarks are all broken at the moment and don't do anything. They all fail with
base-common-no-such-file. This PR addresses the following:create_tmp_file(), aTempDirobject is created. When the function returns, the directory is deleted onTempDir::drop(). Callingsetup_test_file()fixes this, as it solves this problem by callingstd::mem::forget()on the directory.uumain(). However, that call touumain()doesn't do what is intended.argv[0]is the program name and theformat!(">{in_file_str}")argument is interpreted, as the input file name forbase64. That file doesn't exist and the benchmark file doesn't get generated. I don't think a shell-like usage of>to redirect stdout works here. Perhaps it's a good idea to add a-ofile to accomplish that? Similarly to how the macOSbase64command has this option.