Right now any engine implementing Repeater is expected to also
implement RepeatReuse. This imposition is strictly unnecessary, but
also makes the number of possible combinations easier to handle for
now.
The reason for adding RepeatReuse is due to benchmarks done by
@mattn who has found that the Repeat function in Gorgonia causes a
lot of additional allocation. Given that gorgonia.org/gorgonia can
actually determine ahead of time how much space to use, a RepeatReuse
API was designed rapidly to allow taking advantage of that.
We cannot just tack on a FuncOpt to Repeat as the variadic
parameters are reserved for the number of repeats to be made. Thus a
new function RepeatReuse is required. Originally the name was
RepeatWithReuse but that is a rather long name.
Coverage increased (+0.02%) to 73.043% when pulling 3b4a5054973e312dce505c8b7c1901d0ad470987 on RepeatReuse into 6848ca2e9a6c44d93bec0814b30ded143c75ca94 on master.
Right now any engine implementing Repeater is expected to also implement RepeatReuse. This imposition is strictly unnecessary, but also makes the number of possible combinations easier to handle for now.
The reason for adding
RepeatReuse
is due to benchmarks done by @mattn who has found that theRepeat
function in Gorgonia causes a lot of additional allocation. Given that gorgonia.org/gorgonia can actually determine ahead of time how much space to use, a RepeatReuse API was designed rapidly to allow taking advantage of that.We cannot just tack on a
FuncOpt
toRepeat
as the variadic parameters are reserved for the number of repeats to be made. Thus a new functionRepeatReuse
is required. Originally the name wasRepeatWithReuse
but that is a rather long name.