Martin Huschenbett caedc72551 Implement a simple profiler for DAML scenarios (#5957) ... * Implement a simple profiler for DAML scenarios The profiler runs a single scenario and records timing information when each function (and some other closures) are entered and left. The resulting information can be visualized as a flamegraph using [speedscope](https://www.speedscope.app/). The profiler works by instrumenting the CEK machine at the heart of DAML Engine. Unfortunetaly, this causes a very small overhead on non-profiling runs too. However, in my benchmarks I could not measure any significant impact on the overall runtime at all. More precisely, the overhead is as follows: Every closure now has an additional field called `label`. In non-profiling runs this field is always set to `null`. This field needs to be allocated, copied whenever we copy a closure and scanned during garbage collection. Additionally, whenever we enter a closure, we check this field and whenever it is _not_ `null`, i.e. never during non-profiling runs, we record an "open event" and set up a hook for the corresponding "close event". Thus, the additional cost during non-profiling runs are a single pointer comparison and a jump beyond the "then branch". Since this is still very much in active development, there are no documentation, other than an entry in a README, and no tests yet. They will come before we promote this. However, the UX will look very different then since we already have plans to significantly change it. CHANGELOG_BEGIN CHANGELOG_END * Run scalafmt * Make profiling argument to PureCompiledPackges optional * Fix a bunch of tests CHANGELOG_BEGIN CHANGELOG_END * scalafmt is so annoying CHANGELOG_BEGIN CHANGELOG_END * Apply simple suggestions CHANGELOG_BEGIN CHANGELOG_END		2020-05-18 17:20:44 +00:00
..
src/main	Implement a simple profiler for DAML scenarios (#5957)	2020-05-18 17:20:44 +00:00
BUILD.bazel	Use com.daml as root package (#5343)	2020-04-05 19:49:57 +02:00