[Cuis-dev] usefulness of a faster #timesRepeat?
juan at jvuletich.org
Sun Nov 10 05:56:37 PST 2019
Hi Andrés, Folks,
The attach is a slight rework to avoid evaluating many times a block
that might take a long time to run. It also allows us doing '[ stuff ]
benchFor: 1.5 seconds' for example.
Please take a look.
On 11/9/2019 1:18 AM, Andres Valloud via Cuis-dev wrote:
>>> First, especially in 32 bit systems, it's very important never to
>>> send timesRepeat: to a large integer --- this is why the large
>>> integer method splits the process in rounds of timesRepeat: sent to
>>> small integers.
>> I guess you mean 'never run the iteration on LargeInteger
>> arithmetic', so with the splitting in LargePositiveInteger, sending
>> timesRepeat: to a large integer is ok...
> Yeah, that's what I meant. If you only had the simple implementation
> in Integer, then the to:do: will create large integers for every
> iteration. That is a) slow in itself, and b) creates garbage that
> later has to be collected.
>> Interesting. Not the case in Cuis, where there is no Compiler
>> optimization of #timesRepeat:
> Right --- if that did happen though, then we'd be looking at writing
> timesRepeat: [aBlock value].
>> Still, I wasn't explicit on what I really wanted to ask... My
>> question is: Is #bench (or bench: seconds) a good replacement for
>> #timesRepeat:? If so, does still make sense to have an optimized
>> version of #timesRepeat:?
> If there was bench: seconds, and if that accepted a float argument so
> one could say things like bench: 1.5 and things like that, then the
> timesRepeat: improvement would be less important for this use case.
> The timesRepeat: improvements might still matter, but we'd have to
> find another justification for them first.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Cuis-dev