chshersh / dr-cabal Goto Github PK

Here is a build profile for https://hackage.haskell.org/package/streams:

Legend
  ▇  Downloading
  ▇  Starting
  ▇  Building
  ▇  Haddock
  ▇  Installing

Summary
  Wall time               : 1m56s
  Dependency sum time     : 4m35s
  Total dependencies      : 20
  Parallelism level       : 2.36
  Single block resolution : 634ms

Profile
unordered-containers-0.2.19.1 [33s648ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
                   free-5.1.9 [30s560ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
          semigroupoids-5.3.7 [24s502ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
            bifunctors-5.5.13 [23s326ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
            profunctors-5.6.2 [19s391ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
       th-abstraction-0.4.5.0 [19s375ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
    indexed-traversable-0.1.2 [16s914ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
             hashable-1.4.1.0 [15s459ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
    transformers-compat-0.7.2 [13s777ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
            adjunctions-4.4.2 [11s642ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
                comonad-5.0.8 [9s294ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
               tagged-0.8.6.1 [9s206ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
          contravariant-1.5.5 [8s873ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
         distributive-0.6.2.1 [7s433ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇
               StateVar-1.2.2 [5s886ms ] │ ▇▇▇▇▇▇▇▇▇▇▇
                   boring-0.2 [5s854ms ] │ ▇▇▇▇▇▇▇▇▇▇▇
              semigroups-0.20 [5s403ms ] │ ▇▇▇▇▇▇▇▇▇▇▇
      transformers-base-0.4.6 [5s292ms ] │ ▇▇▇▇▇▇▇▇▇▇
           base-orphans-0.8.7 [4s972ms ] │ ▇▇▇▇▇▇▇▇▇▇
                   void-0.7.3 [4s707ms ] │ ▇▇▇▇▇▇▇▇

This data looks like it's unordered-containers who is a bottleneck, and one could imagine that removing this dependency might decrease observed build times. But the truth is that unordered-containers is built in parallel with kmettoverse and do not contribute into the total wall clock time at all, so its removal would not make things faster.

We could make the output of dr-cabal more actionable by highlighting the critical path in the graph of dependencies, showing actual culprits of long compilation times. E. g.,

Legend
  ▇  Downloading
  ▇  Starting
  ▇  Building
  ▇  Haddock
  ▇  Installing
  *  Critical path

Summary
  Wall time               : 1m56s
  Dependency sum time     : 4m35s
  Total dependencies      : 20
  Parallelism level       : 2.36
  Single block resolution : 634ms

Profile
unordered-containers-0.2.19.1  [33s648ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
                   free-5.1.9* [30s560ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
          semigroupoids-5.3.7* [24s502ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
            bifunctors-5.5.13* [23s326ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
            profunctors-5.6.2  [19s391ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
       th-abstraction-0.4.5.0  [19s375ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
    indexed-traversable-0.1.2* [16s914ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
             hashable-1.4.1.0  [15s459ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
    transformers-compat-0.7.2  [13s777ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
            adjunctions-4.4.2* [11s642ms] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
                comonad-5.0.8* [9s294ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
               tagged-0.8.6.1  [9s206ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
          contravariant-1.5.5  [8s873ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
         distributive-0.6.2.1  [7s433ms ] │ ▇▇▇▇▇▇▇▇▇▇▇▇▇
               StateVar-1.2.2  [5s886ms ] │ ▇▇▇▇▇▇▇▇▇▇▇
                   boring-0.2  [5s854ms ] │ ▇▇▇▇▇▇▇▇▇▇▇
              semigroups-0.20  [5s403ms ] │ ▇▇▇▇▇▇▇▇▇▇▇
      transformers-base-0.4.6  [5s292ms ] │ ▇▇▇▇▇▇▇▇▇▇
           base-orphans-0.8.7  [4s972ms ] │ ▇▇▇▇▇▇▇▇▇▇
                   void-0.7.3  [4s707ms ] │ ▇▇▇▇▇▇▇▇

The sum of build times along the critical path is 30.560+24.502+23.326+16.914+11.642+9.294 = 116.238, precisely explaining the total wall time 1m56s.

I scribbled a quick-and-dirty implementation at https://github.com/Bodigrim/dr-cabal.

Following the instructions on the readme:

> cabal --store-dir=$(mktemp -d) build --dependencies-only all | dr-cabal profile
Missing: (-i|--input FILE_PATH)

Usage: dr-cabal profile (-i|--input FILE_PATH) [-s|--stacked]

Is --input required or can dr-cabal read from stdin?

I installed today with cabal install dr-cabal so that would be dr-cabal-0.2.0.0 wouldn't it?

> dr-cabal --version
Invalid option `--version'

The README.md currently includes the suggestion:

⚠️ WARNING: To get meaningful results, including downloading
of packages, the dr-cabal watch command needs to be run when
none of the dependencies are build (i.e. with cold cabal
cache). If you've already build you project, including
dependencies, you can purge global Cabal cache using the
following command:

rm -rf ~/.cabal

This is a bad idea as it deletes more than necissary to clear the cabal cache, notably the global Cabal configuration file ~/.cabal/config. The absence of this global configuration file will prevent cabal from working during subsequent invocations.

The readme suggests the following command to clear the cabal cache:

rm -rf ~/.cabal

But that also removes other stuff, such as installed binaries, logs, and the cabal config.
It will also become outdated as soon as cabal 3.10 is out (it supports xdg).
A safer suggestion would be

# Remove built dependencies (reset "build" cache)
rm -r ${XDG_STATE_HOME:-~/.local/state}/cabal
rm -r ~/.cabal/store

# Remove downloaded packages (reset "download" cache)
rm -r ${XDG_CAHCE_HOME:-~/.cache}/cabal
rm -r ~/.cabal/packages

Each library might be a dependency of multiple libraries. So it could be beneficial to know the following:

• How many packages depend on it?
• Cumulative stats of all dependencies of a particular dependency (e.g. combine aeson and all its dependencies under the same umbrella)
• Display the difference between actual time when each dependency build only once and total time if all dependencies are needed to be built every time

Writing a reminder to create more issues for the following improvements (so I won't forget them later but I don't have the time to create all the issues at the moment):

• Use functions from ansi-terminal to switch between screen buffers
• Print something in normal screen after Ctrl+C or exception
• Use compact legend in alternate screen buffer
• Display a warning in the alternate screen buffer that only first X lines will be displayed

I'd like to add an interactive mode, which combines watch and profile without an intermediate file, streaming Cabal output into plotter. Here is a demo (sorry for a large GIF):

Moving to Iris - a Haskell CLI framework, allows to add a few features easier:

• The --version flag
• The --non-interactive flag
• Support for colours

and generally allows to introduce a nicer and simple structure to the project.

This should be done after the v0.1.0.0 release of Iris since it contains some breaking changes and a few features

I'd like to suggest an even less intrusive approach, without nuking the whole store:

cabal --store-dir=foobar build

Cabal will create if non-existent and use foobar folder to store built packages.

POSIX users can simplify their lifes even further, creating a fresh temporary folder every time:

cabal --store-dir=$(mktemp -d) build

When building dependencies, you can ask cabal to also build their documentation. This is represented by the Haddock step in the output like this:

Building     base-orphans-0.8.6 (lib)
Haddock      base-orphans-0.8.6 (lib)
Installing   base-orphans-0.8.6 (lib)
Completed    base-orphans-0.8.6 (lib)

Currently, this phase is not supported by dr-cabal but it should be pretty straightforward to add it. Implementation plan:

1. Add new Haddock status here:

2. Add the new phase here:

3. Update phases calculation:

4. Update legend:

5. Update profile output:

Shouldn't be too difficult as the format is quite predictable as well.

It would be good to display the parallelism level (dependency sum build time / wall time) metric in Summary to give insights into the parallelism efficiency.

Current summary:

Summary
  Total dependency build time : 16s732ms
  Single block resolution     : 203ms

Profile
           tasty-1.4.2.3 [11s980ms]  ...
             clock-0.8.3 [4s696ms ] ...
           wcwidth-0.0.2 [3s75ms  ] ...
unbounded-delays-0.1.1.1 [2s936ms ] ...

Should be:

Summary
  Wall time               : 16s732ms
  Dependency sum time     : 23s362ms
  Total dependencies      : 4
  Parallelism level       : 1.39
  Single block resolution : 203ms

Profile
           tasty-1.4.2.3 [11s980ms]  ...
             clock-0.8.3 [4s696ms ] ...
           wcwidth-0.0.2 [3s75ms  ] ...
unbounded-delays-0.1.1.1 [2s936ms ] ...

Summary is printed here:

• Update package version
• Write CHANGELOG
• Update screenshots in README
• Create a GitHub release afterwards

Hello and thanks a lot for the magnificent (as usual) tool! I absolutely love it.

Once, I wanted to share the results of profiling pandoc build (a huge build time sink) with friendly folks over on the pandoc bug tracker. But how should I do it? I can upload the json file and ask them to run dr-cabal locally. Although great for dr-cabal adoption, this is not the easiest on the folks.

Another idea is to create a gist, which is what I tried. Although bearable, it hides the portions of time spent for different phases of building per package (e.g. downloading vs. building). OTOH, I'm not sure everything else besides buliding time there is that interesting.

One probable solution is a simple web UI where I could drag-n-drop the json file and get a permalink for the result. Of course, this may require a non-trivial effort. Avoidable if the format would be supported by existing web apps to draw charts (google charts, speedscope, etc.) I didn't look into your json format, so can't say how realistic it is.

I have two suggestions to improve README:

1. dr-cabal plots external dependencies only, but not the package itself, so there is little benefit to build the latter. Could we suggest to use cabal build --dependencies-only, so that users do not wait for anything else?

2. Shall we advertise interactive mode as the default one, instead of two-step approach with watch and profile?

Currently, the profile command outputs Horizontal Stacked Chart with times taken for each phase. But it would be also cool to have another view mode: Horizontal Interval Stacked Chart.

Instead of time taken for each phase, it should represent when something started and finished. Some idea can be taken from this example but it's not entirely the match:

• https://observablehq.com/@tezzutezzu/world-history-timeline

I imagine it should be possible to reuse some parts of the DrCabal.Profile module and not rewrite everything entirely.

After #29, I propose to change CLI in the following way:

• Keep only profile command (remove watch and interactive)
• dr-cabal profile should use new interactive mode by default
• The profile command has the --to-file | --from-file option to control whether it should save the output to the file or just print the result from the file (by default, no file is used)