bench: update logging benchmarks #26957

pull jonatack wants to merge 6 commits into bitcoin:master from jonatack:2023-01-update-logging-benchmarks changing 2 files +56 −13
  1. jonatack commented at 5:16 pm on January 23, 2023: contributor

    Update our logging benchmarks for evaluating ongoing work like #25203 and refactoring proposals like #26619 and #26697.

    • make the logging benchmarks order-independent (Larry Ruane)
    • add missing benchmarks for the LogPrintLevel and LogPrintfCategory macros that our logging is migrating to; at some later point it should be feasible to drop some of the previous logging benchmarks
    • update the logging benchmark naming to be clear which benchmark corresponds to which log macro, and update the ordering to be the same as the output
    • add clarifying documentation to the logging benchmarks
    • improve the -debuglogfile config option help to be clearer; can be tested by running ./src/bitcoind -help | grep -A4 '\-debuglogfile'

    Reviewers can run the logging benchmarks with:

    0./src/bench/bench_bitcoin -filter='LogP*.*'
    
  2. DrahtBot commented at 5:16 pm on January 23, 2023: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Reviews

    See the guideline for information on the review process.

    Type Reviewers
    ACK LarryRuane, martinus, achow101
    Concept ACK kouloumos

    If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #27231 (Fix logging RPC and -debugexclude with 0/none values, add test coverage, improve docs by jonatack)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  3. DrahtBot added the label Tests on Jan 23, 2023
  4. in src/bench/logging.cpp:40 in eddf2d21ee outdated
    71     Logging(bench, {"-nodebuglogfile", "-debug=1"}, [] {
    72+        LogPrintLevel(BCLog::VALIDATION, BCLog::Level::Error, "%s\n", "test");
    73+        LogPrint(BCLog::VALIDATION, "%s\n", "test");
    74+        LogPrintfCategory(BCLog::VALIDATION, "%s\n", "test");
    75         LogPrintf("%s\n", "test");
    76-        LogPrint(BCLog::NET, "%s\n", "test");
    


    kouloumos commented at 5:35 pm on January 23, 2023:
    The way this benchmark is implemented, we can identify a regression between code changes. But if we wanted to get a sense of how logging without a a debug.log file compares to logging with a debug.log file, this doesn’t help, right? It should only log with one of {LogPrintLevel, LogPrint, LogPrintfCategory} in order to compare the result with one of the other benchmarks.

    jonatack commented at 6:18 pm on January 23, 2023:

    That benchmark was added in fa31dc9b714 with the intention expressed in #18815 (comment), i.e. to test this code currently in setup_common:

     0/**
     1 * Make a test setup that has disk access to the debug.log file disabled. Can
     2 * be used in "hot loops", for example fuzzing or benchmarking.
     3 */
     4template <class T = const BasicTestingSetup>
     5std::unique_ptr<T> MakeNoLogFileContext(const std::string& chain_name = CBaseChainParams::REGTEST, const std::vector<const char*>& extra_args = {})
     6{
     7    const std::vector<const char*> arguments = Cat(
     8        {
     9            "-nodebuglogfile",
    10            "-nodebug",
    11        },
    12        extra_args);
    13
    14    return std::make_unique<T>(chain_name, arguments);
    15}
    

    jonatack commented at 7:06 pm on January 23, 2023:
    Thanks @kouloumos. Decided to add a comment to clarify the intention behind that -nodebuglogfile bench, and not add macros to it per your suggestion.
  5. jonatack force-pushed on Jan 23, 2023
  6. jonatack force-pushed on Jan 23, 2023
  7. in src/bench/logging.cpp:80 in 9d708dbe59 outdated
    71+    // Disable writing the log to a file, e.g. for unit tests or fuzzing.
    72     Logging(bench, {"-nodebuglogfile", "-debug=1"}, [] {
    73         LogPrintf("%s\n", "test");
    74-        LogPrint(BCLog::NET, "%s\n", "test");
    75+        LogPrint(BCLog::VALIDATION, "%s\n", "test");
    76     });
    


    kouloumos commented at 1:52 pm on January 27, 2023:
    I did not realize the purpose of this benchmark at first, and having a comment there makes sense. May I suggest something more direct? Like: “This benchmarks the logging configuration used by the testing setup, see MakeNoLogFileContext

    jonatack commented at 9:47 pm on February 24, 2023:
    Thanks @kouloumos – updated to “Disable writing the log to a file, as used for unit tests and fuzzing in MakeNoLogFileContext.”
  8. in src/bench/logging.cpp:45 in 9d708dbe59 outdated
    34+static void LogPrintWithCategory(benchmark::Bench& bench)
    35+{
    36+    Logging(bench, {"-logthreadnames=0", "-debug=net"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    37+}
    38+
    39+static void LogPrintWithoutCategory(benchmark::Bench& bench)
    


    kouloumos commented at 3:19 pm on January 27, 2023:

    Before this PR, the logging benchmarks were only using the LogPrintf and LogPrint macros. Those have been renamed:

    • LoggingYoThreadNames -> LogPrintfWithThreadNames
    • LoggingNoThreadNames -> LogPrintfWithoutThreadNames
    • LoggingYoCategory -> LogPrintWithCategory
    • LoggingNoCategory -> LogPrintWithoutCategory
    • LoggingNoFile -> LogWithoutWriteToFile

    There is something that puzzles me.

    This is the result I get when running the new benchmarks with src/bench/bench_bitcoin -filter=LogP.* -min-time=5000:

    PR branch (9d708dbe598d096f277ee7ee3078423f416ece1b)

    ns/op op/s err% ins/op cyc/op IPC bra/op miss% total benchmark
    6,695.43 149,355.54 0.2% 22,379.28 9,404.03 2.380 4,522.98 0.2% 5.50 LogPrintLevelWithThreadNames
    6,472.74 154,494.18 0.2% 21,721.01 8,977.58 2.419 4,357.01 0.1% 5.45 LogPrintLevelWithoutThreadNames
    6,426.44 155,607.13 0.1% 21,447.01 8,893.94 2.411 4,292.01 0.1% 5.37 LogPrintWithCategory
    6,413.88 155,911.77 0.1% 21,447.01 8,874.71 2.417 4,292.01 0.1% 5.34 LogPrintWithoutCategory
    6,554.13 152,575.56 0.2% 21,905.78 9,140.18 2.397 4,407.96 0.1% 5.42 LogPrintfCategoryWithThreadNames
    6,383.81 156,646.25 0.2% 21,320.76 8,819.82 2.417 4,259.87 0.1% 5.37 LogPrintfCategoryWithoutThreadNames
    6,493.25 154,006.16 0.2% 21,697.01 9,026.45 2.404 4,349.01 0.1% 5.48 LogPrintfWithThreadNames
    6,401.44 156,214.93 0.1% 21,143.74 8,857.86 2.387 4,207.97 0.2% 5.36 LogPrintfWithoutThreadNames

    But if you compare LogPrintWithoutCategory with the results of its previous results (under the name LoggingNoCategory) in #26697#pullrequestreview-1253717862 you see a different result, which is the correct cause logging without category should be fast.

    Now, if you just run that benchmark by itself with src/bench/bench_bitcoin -filter=LogPrintWithoutCategory -min-time=5000 you get the correct result

    ns/op op/s err% ins/op cyc/op IPC bra/op miss% total benchmark
    11.89 84,122,117.23 0.2% 78.00 23.59 3.307 14.00 0.0% 5.49 `LogPrintWithoutCategory

    This “wrong” behavior is also observed when all the benchmarks are run with src/bench/bench_bitcoin Should we consider this an issue? It might result to confusion in the future. I am looking to understand why this is happening but haven’t found anything yet.

    edit: @LarryRuane you mentioned that you also ran those update benchmarks. Can you confirm that you also observe this behavior?


    LarryRuane commented at 6:38 pm on January 28, 2023:

    @kouloumos I’m seeing the same thing. After investigation, I found that the problem is that the global logging object instance is not re-created for each run. When LogPrintWithoutCategory runs, it still has logging categories enabled from the previous benchmark runs.

    This patch fixes the problem for me, give it a try. The change to LogInstance() looks racy (i.e. what if two threads both see g_logger is null, and they both create a new object), but this change is safe because LogInstance() first runs as part of the global static initialization, before main() is called, so there’s only one thread. But if there’s concern about this, std::call_once() can be used (it’s used in a few places already).

     0diff --git a/src/bench/logging.cpp b/src/bench/logging.cpp
     1index d5c78932bc..434d1c58d4 100644
     2--- a/src/bench/logging.cpp
     3+++ b/src/bench/logging.cpp
     4@@ -9,6 +9,7 @@
     5 
     6 static void Logging(benchmark::Bench& bench, const std::vector<const char*>& extra_args, const std::function<void()>& log)
     7 {
     8+    LogReset();
     9     TestingSetup test_setup{
    10         CBaseChainParams::REGTEST,
    11         extra_args,
    12diff --git a/src/logging.cpp b/src/logging.cpp
    13index 8bf60169b0..24f3338368 100644
    14--- a/src/logging.cpp
    15+++ b/src/logging.cpp
    16@@ -18,6 +18,8 @@
    17 const char * const DEFAULT_DEBUGLOGFILE = "debug.log";
    18 constexpr auto MAX_USER_SETABLE_SEVERITY_LEVEL{BCLog::Level::Info};
    19 
    20+static BCLog::Logger* g_logger;
    21+
    22 BCLog::Logger& LogInstance()
    23 {
    24 /**
    25@@ -35,10 +37,16 @@ BCLog::Logger& LogInstance()
    26  * This method of initialization was originally introduced in
    27  * ee3374234c60aba2cc4c5cd5cac1c0aefc2d817c.
    28  */
    29-    static BCLog::Logger* g_logger{new BCLog::Logger()};
    30+    if (g_logger == nullptr) g_logger = new BCLog::Logger();
    31     return *g_logger;
    32 }
    33 
    34+void LogReset()
    35+{
    36+    delete g_logger;
    37+    g_logger = new BCLog::Logger();
    38+}
    39+
    40 bool fLogIPs = DEFAULT_LOGIPS;
    41 
    42 static int FileWriteStr(const std::string &str, FILE *fp)
    43diff --git a/src/logging.h b/src/logging.h
    44index 16f23a19e8..522923c000 100644
    45--- a/src/logging.h
    46+++ b/src/logging.h
    47@@ -266,6 +266,7 @@ namespace BCLog {
    48 } // namespace BCLog
    49 
    50 BCLog::Logger& LogInstance();
    51+void LogReset(); // testing only
    52 
    53 /** Return true if log accepts specified category, at the specified level. */
    54 static inline bool LogAcceptCategory(BCLog::LogFlags category, BCLog::Level level)
    

    jonatack commented at 9:49 pm on February 24, 2023:
    Thanks for the issue @kouloumos and for finding a fix, @LarryRuane! Added a commit by you at the start of the changes here to fix the order dependency.
  9. in src/bench/logging.cpp:32 in 9d708dbe59 outdated
    31+    Logging(bench, {"-logthreadnames=0"}, [] { LogPrintLevel(BCLog::VALIDATION, BCLog::Level::Error, "%s\n", "test"); });
    32+}
    33+
    34+static void LogPrintWithCategory(benchmark::Bench& bench)
    35+{
    36+    Logging(bench, {"-logthreadnames=0", "-debug=net"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    


    kouloumos commented at 4:02 pm on January 27, 2023:

    What’s the expected behavior when logging with a category that is not specified in -debug=?

    Does logging with BCLog::VALIDATION but with -debug=net means that BCLog::Logger::WillLogCategoryLevel will return false? Therefore LogPrint() will not actually log?


    LarryRuane commented at 6:42 pm on January 28, 2023:

    What’s the expected behavior when logging with a category that is not specified in -debug=?

    It should not log. Note that the LogPrintWithoutCategory benchmark specifies -debug=0 which disables all categories, although this has a problem that I mentioned in my other comment.

    Does logging with BCLog::VALIDATION but with -debug=net means that BCLog::Logger::WillLogCategoryLevel will return false? Therefore LogPrint() will not actually log?

    That’s correct.


    kouloumos commented at 10:06 am on January 29, 2023:

    This is different from what I observe running this benchmark.

    When BCLog::NET was replaced with BCLog::VALIDATION it seems that changing -debug=net to -debug=validation was overlooked. Which per my understanding, means that LogPrintWithCategory should not actually benchmark what is supposed to, but rather be comparable to LogPrintWithoutCategory. This is not true and I only see the expected behavior when I change -debug=net to -debugexclude=validation.

    I will investigate this further.


    LarryRuane commented at 8:26 pm on January 30, 2023:

    I think I figured out this mystery. I’m almost certain you’re right that the test has a mistake in it:

    0Logging(bench, {"-logthreadnames=0", "-debug=net"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    

    This is meant to specify the same category (not the different categories, “net” and VALIDATION). But the confusion is that with this mistake, the benchmark still shows a large ns/op, as if it’s actually logging. I ran this code with the debugger, which shows that it is indeed logging the message. The reason, I just figured out, is that the test framework enables all logging, so when the test specifies -debug=net, that has no effect because all categories are enabled anyway.

    I tried changing that line of benchmark code to:

    0Logging(bench, {"-logthreadnames=0", "-debug=0", "-debug=net"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    

    Note the addition of -debug=0 which should disable all logging. So now what should happen is, the test framework specifies -debug which enables all categories (the test framework arguments occur before the ones we specify here), but then we specify -debug=0 which disables all categories, then add back just the one we want. Now, no logging should actually happen, since we haven’t enabled "validation". And this was the case, no logging occurred (the ns/op was a low number).

    Now, let’s just fix the bug in the test:

    0Logging(bench, {"-logthreadnames=0", "-debug=0", "-debug=validation"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    

    To my surprise, this also had a low ns/op, meaning that it was not logging! How could that be, when we’re explicitly specifying -debug=validation and we’re doing a VALIDATION print?

    Further investigation revealed that when the command line includes -debug=0, then we do not enable any categories specified on the command line! That is, the -debug=0 causes even later -debug=category arguments to be ignored!

    Anyway, I believe this is the fix we want, this gives the expected results (actual logging, a high ns/op):

    0 static void LogPrintWithCategory(benchmark::Bench& bench)
    1 {
    2-    Logging(bench, {"-logthreadnames=0", "-debug=net"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    3+     // the test framework enables all categories by default
    4+    Logging(bench, {"-logthreadnames=0"}, [] { LogPrint(BCLog::VALIDATION, "%s\n", "test"); });
    5 }
    

    jonatack commented at 9:53 pm on February 24, 2023:

    Great points. Fixed the -debug, ensured that we do it where needed, and added this comment at the top of the benchmarks, along with co-author to both of you in this commit (LMK if a name/email is incorrect).

    0+// The test framework currently enables all categories by default, but in case
    1+// that changes, we set -debug=category in the benchmarks below when we expect a
    2+// category to be logged.
    
  10. kouloumos commented at 4:04 pm on January 27, 2023: contributor

    Concept ACK The addition of the new macros makes sense as well as the new names for the benchmarks.

    Just one observation: although I initially was sceptical about the {No,Yo} naming scheme, looking at the updated {With,Without} it seems that is now harder to skim through the list.

  11. jonatack force-pushed on Feb 24, 2023
  12. jonatack commented at 10:03 pm on February 24, 2023: contributor
    Thank you @kouloumos and @LarryRuane for the excellent reviewing. Updated per git diff 9d708db a0e092e
  13. LarryRuane commented at 4:21 am on February 26, 2023: contributor

    ACK a0e092e1af6f8903568d48ebb04ef654a6b71d53

     0$ ./src/bench/bench_bitcoin -filter='LogP*.*'
     1|               ns/op |                op/s |    err% |     total | benchmark
     2|--------------------:|--------------------:|--------:|----------:|:----------
     3|            2,716.93 |          368,062.78 |    0.5% |      0.01 | `LogPrintLevelWithThreadNames`
     4|            2,691.57 |          371,529.69 |    0.4% |      0.01 | `LogPrintLevelWithoutThreadNames`
     5|            2,657.64 |          376,273.25 |    0.3% |      0.01 | `LogPrintWithCategory`
     6|                4.15 |      241,089,995.32 |    0.3% |      0.01 | `LogPrintWithoutCategory`
     7|            2,705.19 |          369,659.92 |    0.2% |      0.01 | `LogPrintfCategoryWithThreadNames`
     8|            2,651.54 |          377,138.94 |    0.1% |      0.01 | `LogPrintfCategoryWithoutThreadNames`
     9|            2,649.92 |          377,370.03 |    0.3% |      0.01 | `LogPrintfWithThreadNames`
    10|            2,613.43 |          382,638.59 |    0.3% |      0.01 | `LogPrintfWithoutThreadNames`
    11|               48.00 |       20,832,403.39 |    0.3% |      0.01 | `LogWithoutWriteToFile`
    

    I believe these are the (rough) results we expect. If you retouch, consider adding a comment at the top of the file probably, stating the expected results – that is, that all but two of the tests should have similar performance, but that LogPrintWithoutCategory should be about 3 orders of magnitude faster than most of the tests, and LogWithoutWriteToFile should be about 2 orders of magnitude faster than most of the tests. Maybe even explain briefly why – for example, LogWithoutWriteToFile is still logging somewhere (?) but not to a file, which is why it’s faster, while LogPrintWithoutCategory should be almost a no-op. Something like that, just so when people run this benchmark, they’ll know roughly what’s expected without having to dig in and really understand the code.

  14. in src/logging.h:204 in 439b31c3a4 outdated
    200@@ -201,6 +201,7 @@ namespace BCLog {
    201 } // namespace BCLog
    202 
    203 BCLog::Logger& LogInstance();
    204+void LogReset(); // for benchmarks and testing
    


    maflcko commented at 10:38 am on February 27, 2023:
    Not sure about leaking test-only code into real code. Have you tried to reset the categories instead?

    LarryRuane commented at 5:29 pm on February 27, 2023:
    Resetting categories would also touch real code, wouldn’t it?

    maflcko commented at 3:57 pm on February 28, 2023:
    Is it not possible to call the existing EnableCategory and disable functions?

    LarryRuane commented at 0:01 am on March 5, 2023:
    Thanks, @MarcoFalke, good suggestion, this branch changes that commit to not touch production code (individual commit) @jonatack, feel free to cherry-pick.

    jonatack commented at 5:20 pm on March 7, 2023:
    Done, thank you @MarcoFalke and @LarryRuane.
  15. in src/bench/logging.cpp:50 in a0e092e1af outdated
    53+    Logging(bench, {"-logthreadnames=0", "-debug=0"}, [] {
    54+        LogPrint(BCLog::VALIDATION, "%s\n", "test");
    55+    });
    56+}
    57+
    58+static void LogPrintfCategoryWithThreadNames(benchmark::Bench& bench)
    


    fanquake commented at 3:14 pm on February 27, 2023:

    In 4db9dc8ac3baa9751702ca575965661e63384692:

    Looks like you’re introducing these benchmarks, with BCLog::NET, only to change them in a later commit (dfb40748911b9553a6e10c8376b032dac36bf938) to BCLog::VALIDATION? It’s not obvious to me why the category needs changing, but this can probably be re-ordered so we aren’t changing the same (newly introduced) lines of code, multiple times in the same PR.


    jonatack commented at 5:21 pm on March 7, 2023:

    Done, thank you @fanquake, the diffs are much smaller now.

    (Also dropped the category change, as it didn’t make sense with an unordered map.)

  16. bench: allow logging benchmarks to be order-independent
    The global logging object instance is not re-created for each run, so when
    multiple logging benchmarks are run, each one after the first one still has
    the logging categories enabled from the previous ones.  This commit disables
    all categories at the start of each benchmark.
    4684aa8733
  17. bench: update logging benchmark naming for clarity
    to better track which benchmark corresponds to which log macro.
    4b3fdbf6fe
  18. bench: order the logging benchmark code by output 102b203349
  19. bench: add LogPrintfCategory and LogPrintLevel benchmarks
    for these new macros that our logging is planned to migrate to.  At some
    point it may be feasible to drop some of the previous logging benchmarks.
    d8deba8c36
  20. jonatack commented at 5:22 pm on March 7, 2023: contributor

    consider adding a comment at the top of the file probably, stating the expected results

    Good idea @LarryRuane (thanks!). Done.

  21. bench: document expected results in logging benchmarks
    and clarify the intention behind the -nodebuglogfile bench.
    
    Co-authored-by: "kouloumos <kouloumosa@gmail.com>"
    Co-authored-by: "Larry Ruane <larryruane@gmail.com>"
    20d89d6802
  22. doc: improve -debuglogfile help to be a bit clearer 8c47d599b8
  23. jonatack force-pushed on Mar 7, 2023
  24. LarryRuane commented at 6:17 pm on March 7, 2023: contributor
    ACK 8c47d599b87d6b2d43e7d37ce0aaf4f541535bb9 The commits are very clean.
  25. in src/bench/logging.cpp:64 in 8c47d599b8
    66+    Logging(bench, {"-logthreadnames=0", "-debug=net"}, [] {
    67+        LogPrintfCategory(BCLog::NET, "%s\n", "test");
    68+    });
    69+}
    70+
    71+static void LogPrintfWithThreadNames(benchmark::Bench& bench)
    


    fanquake commented at 11:07 am on March 8, 2023:

    In 102b2033493f0d61e9763d094cb8a0017f7e3a10 bench: order the logging benchmark code by output:

    Given that the code-movement, and re-ordering the BENCHMARK( calls doesn’t change the output, this seems like a no-op?

    In general, is (re-)ordering code in a .cpp file based on the order functions are called something we do?


    martinus commented at 6:37 am on March 18, 2023:
    Benchmarks are registered into a std::map so they are alphabetically sorted anyways https://github.com/bitcoin/bitcoin/blob/master/src/bench/bench.h#L68

    jonatack commented at 6:46 pm on March 18, 2023:
    As in src/bench/peer_eviction.cpp / ./src/bench/bench_bitcoin -filter='Eviction*.*', I add or keep the benchmark methods in the same alphabetical order as our bench framework prints them as a developer-friendly happiness measure. It’s not required, but I think it’s nice to do.
  26. fanquake assigned fanquake on Mar 16, 2023
  27. martinus commented at 7:36 am on March 18, 2023: contributor

    code review & tested ACK 8c47d599b87d6b2d43e7d37ce0aaf4f541535bb9, here are my benchmark results:

    ns/op op/s err% ins/op cyc/op IPC bra/op miss% total benchmark
    3,822.12 261,634.61 0.3% 22,931.00 8,536.02 2.686 4,512.00 0.1% 0.53 LogPrintLevelWithThreadNames
    3,776.34 264,807.01 0.4% 22,494.01 8,370.09 2.687 4,403.00 0.1% 0.48 LogPrintLevelWithoutThreadNames
    3,733.48 267,846.56 0.5% 22,252.00 8,272.50 2.690 4,351.00 0.1% 0.54 LogPrintWithCategory
    7.25 137,992,883.01 0.5% 71.00 23.04 3.081 16.00 0.0% 0.67 LogPrintWithoutCategory
    3,779.40 264,592.05 0.3% 22,773.01 8,416.90 2.706 4,473.00 0.1% 0.54 LogPrintfCategoryWithThreadNames
    3,709.16 269,602.50 0.4% 22,122.00 8,208.57 2.695 4,318.00 0.1% 0.53 LogPrintfCategoryWithoutThreadNames
    3,737.44 267,562.59 0.4% 22,495.01 8,290.13 2.713 4,399.00 0.1% 0.53 LogPrintfWithThreadNames
    3,630.74 275,425.89 0.1% 21,844.00 7,989.23 2.734 4,244.00 0.1% 0.53 LogPrintfWithoutThreadNames
    100.84 9,916,479.93 0.0% 802.00 320.90 2.499 186.00 0.0% 0.55 LogWithoutWriteToFile

    By the way, here is a nice way to create & share detailed benchmark results, see the results here: https://share.firefox.dev/3Z02boN

    How to do this:

    1. Run a benchmark for a few seconds and record data with perf
      0perf record --call-graph lbr ./src/bench/bench_bitcoin -filter="LogPrintLevelWithoutThreadNames" -min-time=5000
      
    2. Convert into data readable with https://profiler.firefox.com/
      0perf script -F +pid > /tmp/test.perf
      
    3. Drag & drop test.perf into https://profiler.firefox.com/, upload the data, and create a permalink to it
  28. LarryRuane commented at 3:10 pm on March 18, 2023: contributor

    Here’s a suggestion about benchmarking in general, wonder what you think. The idea is a kind of performance regression testing.

    If there are a set of related benchmarks, as there are here, there may be some expected performance relationship between them. (Above I suggested that Jon add a comment describing this relationship, and he did.) It would be cool if this could somehow be specified in the code and checked automatically, and a failure raised if the runtime ratio between the sub-benchmarks exceeded some threshold. So for example, if a bug was introduced that made LogPrintWithoutCategory run at about the same speed as the other types of logging, flag an error.

    What do you think? (Obviously not for this PR, but as a separate PR.)

  29. jonatack commented at 6:56 pm on March 18, 2023: contributor
    @LarryRuane Perhaps reviving https://bitcoinperf.com/ to track changes in benchmarks over time, and alert when it observes a deviation threshold reached, could be a way to implement it. Maybe it could be hooked into the CI at some point.
  30. fanquake unassigned fanquake on Mar 20, 2023
  31. achow101 commented at 8:53 pm on March 23, 2023: member
    ACK 8c47d599b87d6b2d43e7d37ce0aaf4f541535bb9
  32. achow101 merged this on Mar 23, 2023
  33. achow101 closed this on Mar 23, 2023

  34. jonatack deleted the branch on Mar 23, 2023
  35. sidhujag referenced this in commit 433494e1d3 on Mar 24, 2023
  36. bitcoin locked this on Mar 22, 2024

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-22 00:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me