Pushing computing delta into timing module

[arlolra]

Is that desirable?

[earldouglas]

Makes sense to me.

[coveralls]

Coverage increased (+0.02%) to 84.02% when pulling 1f24bdf on delta into 9bc8050 on master.

[coveralls]

Coverage increased (+0.02%) to 84.02% when pulling 1f24bdf on delta into 9bc8050 on master.

[gwicke]

I left it out as passing in the timing seemed slightly more flexible / less magical (can add up several timings to one aggregate etc). Don't care too strongly though.

[arlolra]

The common case is tedious though,
https://gerrit.wikimedia.org/r/#/c/186219/7/api/routes.js

You can always pass in (Date.now() - aggregate) :)

[gwicke]

Maybe the start time could be an optional parameter for the best of both worlds?

[arlolra]

Maybe the start time could be an optional parameter for the best of both worlds?

The signature would start to get ugly. I don't like passing in a null for delta in that case.

I guess just adding a wrapper would suffice.

StatsD.prototype.endTimer = function( name, suffix, start ) {
  return this.timing( name, suffix, Date.now() - start );
}

Or maybe this has been enough of a distraction already :)

[gwicke]

@arlolra, that would work for me. Perhaps call it endTiming instead for some consistency?

[arlolra]

You've s/-/,/ :)

endTiming sounds good. Or, captureTiming? (suggested just to keep this conversation going)

[gwicke]

(suggested just to keep this conversation going)

Ha! We'll move this code to a separate package so that we can share it. Can add the method then.

[arlolra]

Oh ... too late. And I merged in #175.

[coveralls]

Coverage increased (+0.04%) to 84.7% when pulling 0f81eab on delta into bec5db2 on master.

[gwicke]

@arlolra: alright, thank you!