so if you have version that we should integrate let us know: open a BT entry :)
stef On Jun 12, 2009, at 7:18 PM, Nicolas Cellier wrote: > IMHO this is premature optimization. > Please correct milliSeconds: (see nanoSeconds:) > > milliSeconds: milliCount > "Since seconds is 0 we can call the instance directly." > > ^milliCount < 1000 > ifTrue: [ self basicNew seconds: 0 nanoSeconds: milliCount * > NanosInMillisecond ] > ifFalse: [ > | quo | > quo := milliCount quo: 1000. > ^ self basicNew > seconds: quo > nanoSeconds: (milliCount - (quo * 1000)) * > NanosInMillisecond] > > Nicolas > > > 2009/6/12 Henrik Johansen <[email protected]>: >> I assume the // and \\ involved in converting millis to seconds were >> found too slow (see comment for similiar method nanoseconds:, which >> does >> it), therefore it's assumed milliseconds: is always called with value >> 0<value<1000. >> >> However, changing to a version that "auto-translates" to seconds: >> >> milliSeconds: milliCount >> ^ self basicNew seconds: (milliCount // 1000) nanoSeconds: >> (milliCount \\ 1000) * NanosInMillisecond >> (there was no MillisInSecond, I didn't bother adding just for this) >> >> and running some tests against old version: >> >> Time millisecondsToRun: [10000 to: 1000000 do: [:ms | dur := Duration >> milliSeconds: ms]]] 305 >> Time millisecondsToRun: [10000 to: 1000000 do: [:ms | durr := >> Duration >> milliSecondsOld: ms]] 1683 >> with float values: >> Time millisecondsToRun: [10000.0 to: 1000000.0 do: [:ms | dur := >> Duration milliSeconds: ms]]] 1944 2058 2151 >> Time millisecondsToRun: [10000.0 to: 1000000.0 do: [:ms | durr := >> Duration milliSecondsOld: ms]] 5396 5458 5171 >> >> For the small, valid, values though: >> Time millisecondsToRun: [5000 timesRepeat: [1 to: 999 do: [:ix | >> durr := >> Duration milliSeconds: ix]]] 1620 1628 1483 1747 1722 >> Time millisecondsToRun: [5000 timesRepeat: [1 to: 999 do: [:ix | >> durr := >> Duration milliSecondsOld: ix]]] 1549 1670 1525 1498 1651 >> >> So I guess it does make *some* sense, just puts rather strict >> limits on >> the input accepted. >> >> Cheers, >> Henry >> >> Henrik Johansen skrev: >>> Besides, durationToRun has a bug when durationTime is bigger than >>> 1s, >>> calling Duration milliSeconds: durationTime . >>> (Or Duration milliSeconds: has a bug, depending on your point of >>> view) >>> Ex: >>> (In Squeak) >>> Duration milliSeconds: 7666 prints as: 0:00:00:00.7666 >>> (In Pharo) >>> Duration milliSeconds: 7666 prints as: 0:00:00:07.7666 >>> >>> In both cases, A Duration with 0 seconds, and 7666000000 >>> nanoseconds is >>> created. >>> >>> Cheers, >>> Henry >>> >>> Stéphane Ducasse skrev: >>> >>>> on mac >>>> >>>> 0:00:00:00.409 >>>> >>>> On Jun 12, 2009, at 11:43 AM, Gary Chambers wrote: >>>> >>>> >>>> >>>>> Depends if the preference for "higher performance" is enabled >>>>> too... >>>>> >>>>> For comparison (Windows VM, updated 10304cl image): >>>>> >>>>> "higher performance" off: 0:00:00:06.6087 >>>>> "higher performance" on: 0:00:00:00.524 >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- >>>>> From: "Stéphane Ducasse" <[email protected]> >>>>> To: "Pharo Development" <[email protected]> >>>>> Sent: Friday, June 12, 2009 7:12 AM >>>>> Subject: [Pharo-project] Animation bench >>>>> >>>>> >>>>> Hi guys >>>>> >>>>> could you run the following: >>>>> >>>>> >>>>> >>>>>>> [ >>>>>>> (m := Morph new) openInWorld. >>>>>>> 1 to: 300 do: [:i | >>>>>>> m position: m position + (1...@1). >>>>>>> World doOneCycle] >>>>>>> ] >>>>>>> durationToRun >>>>>>> >>>>>>> >>>>> because [email protected] did it and here are the result >>>>> >>>>> * vm : pharo-vm-0.15.1b-linux >>>>> * image : pharo0.1-10332dev09.06.2 >>>>> - Test 1 : Project est vide, juste le workspace ouvert à >>>>> l'opposé du >>>>> trajet >>>>> Résultat 0:00:00:07.704 >>>>> - Test 2 : ClassBrowser recouvrant tout le 'World' >>>>> Résultat : 0:00:00:00.689 >>>>> >>>>> - Test 1 >>>>> * vm : squeak3.9.8-3ubuntu3 >>>>> * image : Squeak-dev 3.10.2 >>>>> - Test 1 : Project est vide, juste le workspace ouvert à >>>>> l'opposé du >>>>> trajet >>>>> Résultat : 0:00:00:02.098 >>>>> - Test 2 : ClassBrowser recouvrant tout le 'World' >>>>> Résultat : 0:00:00:00.608 >>>>> Donc contrairement à ce qu'il semblait être >>>>> logique, >>>>> le morph avance plus vite si le "World" n'est pas vide. >>>>> >>>>> Stéphane Rollandin a écrit : >>>>> >>>>> >>>>>> [ >>>>>> (m := Morph new) openInWorld. >>>>>> 1 to: 300 do: [:i | >>>>>> m position: m position + (1...@1). >>>>>> World doOneCycle] >>>>>> ] >>>>>> durationToRun >>>>>> >>>>>> retourne 0:00:00:00.373 dans mon image, soit un gros tiers de >>>>>> seconde. on est loin des 6 s >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
