janestreet / janestreet/core_bench

would it be possible to reduce the dependencies of core_bench?

Open
#18 10 comments 1 reaction 0 assignees View on GitHub
forwarded-to-js-devs
Dominant language
OCaml
Stars
57
Forks
15
PR merge metrics
No merged PRs in 30d

Description

I would like to use the [faster-map](https://github.com/aantron/faster-map/) benchmark to test ongoing work on tail-recursion-modulo-cons ( https://github.com/ocaml/ocaml/pull/181 ); this means creating an empty switch from an experimental compiler, then building `faster-map`'s dependencies.

The dependencies are as follows: `dune batteries containers core_bench`. Building this from an empty switch is fairly slow on my machine, and most of the time is spent compiling dependencies of `core_bench`:

```
$ time opam install dune
real 0m23.240s
user 0m37.759s
sys 0m10.028s

$ time opam install batteries # deps: ocamlbuild, ocamlfind, num
real 0m34.083s
user 0m28.428s
sys 0m9.122s

$ time opam install containers # deps: dune-private-libs, dune-configurator
real 0m49.980s
user 0m32.759s
sys 0m37.364s

$ time opam install core_bench # deps: core, ppx_jane, many others
real 6m48.733s
user 11m16.617s
sys 4m7.479s
```

Would there be interest among core_bench maintainers to make it more pleasant to use for compiler-optimization microbenchmarking? It may not be that much work to reduce the dependency surface. (I understand that you need access to fine-grained timers, but for example it is not clear why core_bench depends on ppx_jane and many ppx extensions.)

(cc @ksromanov who kindly updated faster-map for TRMC testing.)

Contributor guide

Open the contributing guide

Research direction

The issue does not name a source file or test entry point; start by auditing core_bench's package dependencies, especially core, ppx_jane, and its other ppx extensions. Done means reducing the dependency surface enough to make faster-map's compiler-optimization benchmark setup substantially faster from an empty switch, while retaining the fine-grained timers it needs.

Written by the indexing model from the issue text.

Assessment

Tech stack
ocaml
Domain
performance
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.