3

(reposted from here)

I'm trying to measure/log the running time of a task.

I've looked into "wrapping" a task by adding one task before and one task after but this would not work every time as sbt only guarantees a partial order.

A better wrapping would be something along these lines:

wrappedTask := {
  startMeasuringTime()
  somehowInvoke(myTaskKey in SomeContext)
  endMeasuringTime()
}

What should this "somehowInvoke" be?

cos
  • 219
  • 1
  • 8

1 Answers1

3

Measuring the time taken by a task needs support from the task executor. As you imply, you cannot do this only by using task primitives. I've pushed some sample code that I wrote a while back that shows the idea.

A complication that the sample code doesn't handle is that what the user conceptually thinks of as one task (compile, for example) may actually be implemented as several tasks and those timings would need to be combined. Also, a task like internalDependencyClasspath "calls" other tasks (flatMap) and so its execution time includes the execution time of the "called" tasks.

EDIT: This was implemented for 0.13.0 as an experimental feature in 602c1759a1885 and 1cc2f57e158389759. The ExecuteProgress interface provides sufficient information that the previously described issues are not a problem.

Mark Harrah
  • 6,999
  • 1
  • 26
  • 31
  • Thanks! As I only needed to measure the time of a run, I ended up making a task that wraps a ScalaRun run. – cos Sep 12 '12 at 23:07
  • The ExecuteProgress looks neat. Is it possible to specify one from "outside" of sbt? – cos Sep 12 '12 at 23:09
  • 1
    Not sure what you mean by outside. Although not implemented, you'd possibly configure it like you would `parallelExecution` or now in 0.12, `concurrentRestrictions`. – Mark Harrah Sep 13 '12 at 12:13
  • 1
    Stil learning sbt's implementation... So, this would mean making a key for it and modify `EvaluateTask` to `def progress: ExecuteProgress[Unit, Task] = getSetting(Keys.executeProgress, new ExecuteProgress [...] )`? – cos Sep 13 '12 at 21:36