You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems a little odd that you must call .warmup() even if you've already specified warmup* options when initializing the benchmark. I respect the choice to make warmups explicit, but I think there may be an API that accomplishes both.
The idea is to add a warmup key to Options that can accept boolean | { time?: number; iterations?: number }. If this key is specified & truthy, the benchmark will automatically call .warmup() when run.
This is a non-breaking change since it's a brand new option. Users opt into the "auto warmup" feature by specifying warmup. The existing keys warmupTime and warmupIterations can continue to be supported though you'd presumably throw an informative error if both warmup.time and warmupTime were specified.
Just a thought. Happy to put in a PR if this seems acceptable. Thanks for the great tool!
The text was updated successfully, but these errors were encountered:
It seems a little odd that you must call
.warmup()
even if you've already specifiedwarmup*
options when initializing the benchmark. I respect the choice to make warmups explicit, but I think there may be an API that accomplishes both.The idea is to add a
warmup
key toOptions
that can acceptboolean | { time?: number; iterations?: number }
. If this key is specified & truthy, the benchmark will automatically call.warmup()
when run.This is a non-breaking change since it's a brand new option. Users opt into the "auto warmup" feature by specifying
warmup
. The existing keyswarmupTime
andwarmupIterations
can continue to be supported though you'd presumably throw an informative error if bothwarmup.time
andwarmupTime
were specified.Just a thought. Happy to put in a PR if this seems acceptable. Thanks for the great tool!
The text was updated successfully, but these errors were encountered: