[Pharo-project] I always thought that 1 to: 100 do: was faster than (1 to: 100) do:
but apparently http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
Stef
I bet it's undo history again! reverse the order of the two tests and redo... or deselect the preference for multipletextUndo. 2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
but nicolas this is quite strange I unset the preference and I get 1 to: 1000 -> 3405 ms (1 to: 1000) -> 2600 ms I'm puzzled. Should probably increase the sample.... I redid the experience with exaclty the same setup and I get 26115 vs 25487 so this should be ok Stef On May 3, 2009, at 9:25 PM, Nicolas Cellier wrote:
I bet it's undo history again!
reverse the order of the two tests and redo... or deselect the preference for multipletextUndo.
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
Stef
_______________________________________________ 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
{ [(1 to: 100) do: [:i | i yourself]] bench. [1 to: 100 do: [:i | i yourself]] bench. }. #('6935.01299740052 per second.' '44448.7102579484 per second.') You observe a Transcript dependent behavior, not related to to:do: 2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but nicolas this is quite strange I unset the preference
and I get 1 to: 1000 -> 3405 ms
(1 to: 1000) -> 2600 ms
I'm puzzled. Should probably increase the sample.... I redid the experience with exaclty the same setup and I get 26115 vs 25487 so this should be ok
Stef
On May 3, 2009, at 9:25 PM, Nicolas Cellier wrote:
I bet it's undo history again!
reverse the order of the two tests and redo... or deselect the preference for multipletextUndo.
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
Stef
_______________________________________________ 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
Great! This is a nice example to show all the tools we have for benchmarking. On May 6, 2009, at 8:46 PM, Nicolas Cellier wrote:
{ [(1 to: 100) do: [:i | i yourself]] bench. [1 to: 100 do: [:i | i yourself]] bench. }. #('6935.01299740052 per second.' '44448.7102579484 per second.')
You observe a Transcript dependent behavior, not related to to:do:
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but nicolas this is quite strange I unset the preference
and I get 1 to: 1000 -> 3405 ms
(1 to: 1000) -> 2600 ms
I'm puzzled. Should probably increase the sample.... I redid the experience with exaclty the same setup and I get 26115 vs 25487 so this should be ok
Stef
On May 3, 2009, at 9:25 PM, Nicolas Cellier wrote:
I bet it's undo history again!
reverse the order of the two tests and redo... or deselect the preference for multipletextUndo.
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
Stef
_______________________________________________ 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
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently    http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
i added a comment to this issue.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor, you're claiming that every reference to Transcript in every package and every example should be wrapped in some way by [ ... ] forkAt: Processor userBackgroundPriority. to preserve the historical behavior ? 2009/5/3 Igor Stasenko <siguctua@gmail.com>:
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently    http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
i added a comment to this issue.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/5/3 Hernán Morales Durand <hernan.morales@gmail.com>:
 Igor, you're claiming that every reference to Transcript in every package and every example should be wrapped in some way by
[ ... Â ] forkAt: Processor userBackgroundPriority.
to preserve the historical behavior ?
No, i'm not. It is the Transcript which ensuring the thread-safety. Transcript is a stream. It could be used w/o being connected to a window. Please make difference between Transcript stream, which is updated immediately, and Transcript window which can be updated when it is safe to do it.
2009/5/3 Igor Stasenko <siguctua@gmail.com>:
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
but apparently    http://code.google.com/p/pharo/issues/detail?id=750 shows the contrary and this is really strange. I think that may be this is a slow down in Transcript but...
i added a comment to this issue.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Hernán Morales Durand -
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse