[llvm-exegesis] Analysis: writeMeasurementValue(): don't alloc string for double each time.

[lebedev.ri]

Summary

Test data: 500kLOC of benchmark.yaml, 23Mb. (that is a subset of the actual uops benchmark i was trying to analyze!)
Old time: (D54382)

 Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=100000 -benchmarks-file=/tmp/benchmarks.yaml -analysis-inconsistencies-output-file=/tmp/clusters.html' (16 runs):

       9024.354355      task-clock (msec)         #    1.000 CPUs utilized            ( +-  0.18% )
...
            9.0262 +- 0.0161 seconds time elapsed  ( +-  0.18% )

New time:

 Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=100000 -benchmarks-file=/tmp/benchmarks.yaml -analysis-inconsistencies-output-file=/tmp/clusters.html' (16 runs):

       8996.541057      task-clock (msec)         #    0.999 CPUs utilized            ( +-  0.19% )
...
            9.0045 +- 0.0172 seconds time elapsed  ( +-  0.19% )

-~0.3%, not that much. But this isn't the important part.

Old:

• calls to allocation functions: 2109712
• temporary allocations: 33112
• bytes allocated in total (ignoring deallocations): 4.43 GB

New:

• calls to allocation functions: 2095345 (-0.68%)
• temporary allocations: 18745 (-43.39% !!!)
• bytes allocated in total (ignoring deallocations): 4.31 GB (-2.71%)

[gchatelet]

I'm not entirely convinced here:

• The code is harder to read,
• the formatting pattern and the SmallString size may go out of sync,
• the performance win is not that big.

tools/llvm-exegesis/lib/Analysis.cpp

101

Why 1 + ...?

[lebedev.ri]

In D54383#1295235, @gchatelet wrote:

I'm not entirely convinced here:

• The code is harder to read,

I can totally bloat it will some comments/variables.

• the formatting pattern and the SmallString size may go out of sync,

*May*.
Or may be removed completely, and this change was be pointless.
Or it may stay like this forever.
Who knows?
Right now this is a clear win from perf/memory standpoint.

• the performance win is not that big.

Given the total perf improvement this patchset provides (or rather, the starting point) i will pretend i did not notice this point :)

tools/llvm-exegesis/lib/Analysis.cpp

101

You will need at most max_digits10 digits PLUS the decimal separator (.) to print the double.

[lebedev.ri]

• Bloated the code with temporary variables to explain everything.
• Provide actual benchmark.

[lebedev.ri]

@courbet thank you for the review!

tools/llvm-exegesis/lib/Analysis.cpp

 //===-- Analysis.cpp --------------------------------------------*- C++ -*-===//
 //
 //                     The LLVM Compiler Infrastructure
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #include "Analysis.h"
 #include "BenchmarkResult.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/Support/FormatVariadic.h"
+#include <limits>
 #include <unordered_set>
 #include <vector>
 
 namespace llvm {
 namespace exegesis {
 
 static const char kCsvSep = ',';
 
writeClusterId(llvm::raw_ostream &OS,
   else if (CID.isError())
     writeEscaped<Tag>(OS, "[error]");
   else
     OS << CID.getId();
 }
 
 template <EscapeTag Tag>
 static void writeMeasurementValue(llvm::raw_ostream &OS, const double Value) {
-  writeEscaped<Tag>(OS, llvm::formatv("{0:F}", Value).str());
+  writeEscaped<Tag>(
+      OS, llvm::formatv("{0:F}", Value)
+              .sstr<1 + std::numeric_limits<decltype(Value)>::max_digits10>());
 }
 
 template <typename EscapeTag, EscapeTag Tag>
 void Analysis::writeSnippet(llvm::raw_ostream &OS,
                             llvm::ArrayRef<uint8_t> Bytes,
                             const char *Separator) const {
   llvm::SmallVector<std::string, 3> Lines;
   // Parse the asm snippet and print it.