mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 17:28:46 +03:00
caedc72551
* 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 |
||
---|---|---|
.. | ||
daml | ||
runner | ||
service | ||
tests |