[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 frederic.ferrere@free.fr 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
My results : VM Mac (john) : 4.1.1b2U 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 <stephane.ducasse@inria.fr> a écrit :
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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <luc.fabresse@gmail.com>
My results :
VM Mac (john) : 4.1.1b2U 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 <stephane.ducasse@inria.fr> a écrit :
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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr 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" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <henrik.s.johansen@veloxit.no>:
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" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <henrik.s.johansen@veloxit.no>:
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" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 frederic.ferrere@free.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Adrian Lienhard -
Gary Chambers -
Henrik Johansen -
Luc Fabresse -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse