Em 18-07-2013 03:03, Aaron Patterson escreveu:
> On Thu, Jul 18, 2013 at 07:59:34AM +0900, phluid61 (Matthew Kerwin) wrote:
>> Issue #8640 has been updated by phluid61 (Matthew Kerwin).
>>
>>
>> tenderlovemaking (Aaron Patterson) wrote:
>>> On Wed, Jul 17, 2013 at 01:04:37PM +0900, phluid61 (Matthew Kerwin) wrote:
>>>   > Since the discussion has moved towards defining two separate methods {#elapsed => (float)s and #elapsed_nanoseconds => (int)ns} I do prefer a keyword argument {in: :nanoseconds}.  Sorry for wavering back and forth on the issue so noisily.
>>>   
>>>   I don't care if a method exists that has kw args, but I would not use
>>>   it.  The things we need to time in Rails are fairly fast (say 200ms on
>>>   the slow side) and happen frequently, which means that object
>>>   allocations matter.  A kwarg method will end up allocating a hash on
>>>   every call.
>>>   
>>>   If someone else wants to make a method with kwargs, I think that's
>>>   great, but it's not what I'm pushing for here.  My point is to reduce
>>>   object allocations.  :-)
>>>   
>> In that case, would #8096 be a better proposal?  Since that one doesn't even allocate a Time object.
> I don't think so.  We need subsecond resolution, which (if we used
> #8096) would require a possible bignum allocation (from what I gather in
> the ticket).

But I believe he has a point, Aaron. Maybe we should avoid allocating a 
time object (Time.now) and instead introduce something like Java's 
System.currentTimeMillis():

start = Benchmark.start
operation
report start.since_beginning
other_operation
report start.since_beginning # from start= on
report start.since_last_report # since operation

This new object would be lighter than Time as it would only contain the 
start absolute nanoseconds or millis since epoch, maybe.

I haven't given the names much of a thought, but that would be the idea. 
Makes sense?