Animation bench
Locked
 
|
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 [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
My results : Image : pharo0.1-10324dev Just with the workspace windows : 0:00:00:06.6051 With an OBPackageBrowser taking fullscreen : 0:00:00:06.6048
VM Mac (john) : 4.1.1b2U Image : pharo0.1-core10331cl Just with the workspace windows : 0:00:00:06.6047 With an OBPackageBrowser taking fullscreen : 0:00:00:06.6056
Luc Le 12 juin 2009 08:12, Stéphane Ducasse <[hidden email]> a écrit : Hi guys _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
I tried in 10304 (since the fix 832 was introduced in 312).
update10312 "self new update10312" self withUpdateLog:'- 819 argumentCount - stef fixing his methods (tests) - Issue 820: Re-implement Boolean>>#==> that was removed because it was not license clean - Issue 821: Preference to settings refactoring: #confirmFirstUseOfStyle case- Issue 657: About dialog is too big http://code.google.com/p/pharo/issues/detail?id=657 - Issue 832: morphs do not respect the damagerect http://code.google.com/p/pharo/issues/detail?id=832 But the results are the same 0:00:00:06.6055 quite bad :( > 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 [hidden email] 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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" <[hidden email]> To: "Pharo Development" <[hidden email]> 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 [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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" <[hidden email]> > To: "Pharo Development" <[hidden email]> > 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 [hidden email] 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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" <[hidden email]> >> To: "Pharo Development" <[hidden email]> >> 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 [hidden email] 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Luc Fabresse
In windows and "higher performance" disable:
0:00:00:07.7335 0:00:00:07.7292 0:00:00:07.7229 0:00:00:07.7408 In windows and "higher performance" enable: 0:00:00:04.4469 0:00:00:04.4255 0:00:00:04.4153 0:00:00:04.4373 What is this "higher performance" preference? It makes me remember old pcs with the yellow button "Turbo" Why this is not true by default? cheers, Mariano 2009/6/12 Luc Fabresse <[hidden email]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> What is this "higher performance" preference? It makes me remember
> old pcs > with the yellow button "Turbo" > > Why this is not true by default? Because it makes your image slow. For details please see the archive of this list. We've recently discussed this setting and concluded that it should be removed. Cheers, Adrian _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Duration milliSeconds: (was Animation bench)
|
|
In reply to this post by Henrik Sperre Johansen
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" <[hidden email]> >>> To: "Pharo Development" <[hidden email]> >>> 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 [hidden email] 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Duration milliSeconds: (was Animation bench)
|
|
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 <[hidden email]>: > 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" <[hidden email]> >>>> To: "Pharo Development" <[hidden email]> >>>> 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 [hidden email] 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Duration milliSeconds: (was Animation bench)
|
|
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 <[hidden email]>: >> 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" <[hidden email]> >>>>> To: "Pharo Development" <[hidden email]> >>>>> 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 [hidden email] 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 >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |