Open in StackBlitz

npm i https://pkg.pr.new/tinylibs/tinybench@329

commit: e481a91

I don't have strong opinions in terms of API design.

An alternative API could be something like this:

```javascript
bench.add('my task', (handle) => {
  let endTime;
  
  function ReportEndTime() {
    endTime = bench.opts.now();
  }
  
  function BenchmarkComponent() {
    return (
      <>
       {someViews}
       <ReportEndTime />
      </>
    );
  }
  
  const startTime = bench.opts.now();
  render(<BenchmarkComponent />);
  
  handle.overrideDuration(endTime - startTime);
});

Sounds reasonable to propose an object with a keys namespace that can override some tinybench internal measurements. And I do not have any better idea at the moment.
The only issue I see is that the measurement done is not using the timestamping method in tinybench. It would be better for consistency in benchmarking to expose it and try to enforce its usage in that use case.

Sounds reasonable to propose an object with a keys namespace that can override some tinybench internals measurements. And I do not have any better idea at the moment.

Thanks for the reply!

Are you supporting the option in the PR or the alternative solution I suggested in the comment?

Sounds reasonable to propose an object with a keys namespace that can override some tinybench internals measurements. And I do not have any better idea at the moment.

Thanks for the reply!

Are you supporting the option in the PR or the alternative solution I suggested in the comment?

The option in the PR, looks more inline with an "natural" coding experience. My only concerns are about timestamping consistency: #329 (comment)

The only issue I see is that the measurement done is not using the timestamping method in tinybench. It would be better for consistency in benchmarking to expose it and try to enforce its usage in that use case.

How would you suggest we do this?

I see that we can already customize a now option via BenchOptions but it just returns a number. We could introduce a new method to get an opaque benchmark from tinybench that provides a timestamp from it under the hood, but I think that would be unnecessarily complex, as it would now be added on top of the now() method that is already part of the public API.

The only issue I see is that the measurement done is not using the timestamping method in tinybench. It would be better for consistency in benchmarking to expose it and try to enforce its usage in that use case.

How would you suggest we do this?

I see that we can already customize a now option via BenchOptions but it just returns a number. We could introduce a new method to get an opaque benchmark from tinybench that provides a timestamp from it under the hood, but I think that would be unnecessarily complex, as it would now be added on top of the now() method that is already part of the public API.

I have to check, but would it be difficult to add now as a possible argument to bench.add() ?

The only issue I see is that the measurement done is not using the timestamping method in tinybench. It would be better for consistency in benchmarking to expose it and try to enforce its usage in that use case.

How would you suggest we do this?
I see that we can already customize a now option via BenchOptions but it just returns a number. We could introduce a new method to get an opaque benchmark from tinybench that provides a timestamp from it under the hood, but I think that would be unnecessarily complex, as it would now be added on top of the now() method that is already part of the public API.

I have to check, but would it be difficult to add now as a possible argument to bench.add() ?

We could, but the question is how do you force users to use that version instead of any other.

Unless you provide a new API that provides special values and you validate that the custom duration (or custom start/end) uses them, I don't think it's possible.

We could, but the question is how do you force users to use that version instead of any other.

Unless you provide a new API that provides special values and you validate that the custom duration (or custom start/end) uses them, I don't think it's possible.

The idea is to at least offer a way to reuse the custom or the default timestamping easily for that use case. Let's users shoot themselves in the foot if mixing timestamping methods and accuracy. I think we can assume that they have a clue on what they are doing and documentation on proper usage should be enough.

We could, but the question is how do you force users to use that version instead of any other.
Unless you provide a new API that provides special values and you validate that the custom duration (or custom start/end) uses them, I don't think it's possible.

The idea is to at least offer a way to reuse the custom or the default timestamping easily for that use case. Let's users shoot themselves in the foot if mixing timestamping methods and accuracy. I think we can assume that they have a clue on what they are doing and documentation on proper usage should be enough.

Oh, I see. We can add a now() method to Bench that's just the resolved value for the now option. I'll do that and update the documentation.

Edit: the option already exists via bench.opts.now() but it was incorrectly typed as nullable. I fixed that and we can use that in benchmarks (I indicate that in the test).

A 4.1 release will be done shortly after the merge.

Thanks.

thanks for the review, @jerome-benoit !