Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
On Sep 26, 2010, at 7:03 PM, Levente Uzonyi wrote:
On Sun, 26 Sep 2010, Mariano Martinez Peck wrote:
Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev image. If I just take a core image, load OCompletion and run tests, they take a lot of time, not acceptable.
7-8 seconds in Squeak using Cog. and in squeak wihout Cog?
Now....if I build a Dev image (with OB, RB, etc) and at the end I try to run OCompletion tests, the tests takes HOURS. The image seems frozen, but actually is working. If I interrupt I see the problem is in
ECUntypedModel >> initializeSelectors
the part of
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes a lot of time
I know I'm saying this all the time, but it's true: SortedCollection is not suitable for this usage.
Levente
On Sun, 26 Sep 2010, Stéphane Ducasse wrote:
On Sep 26, 2010, at 7:03 PM, Levente Uzonyi wrote:
On Sun, 26 Sep 2010, Mariano Martinez Peck wrote:
Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev image. If I just take a core image, load OCompletion and run tests, they take a lot of time, not acceptable.
7-8 seconds in Squeak using Cog. and in squeak wihout Cog?
21 seconds. Levente
Now....if I build a Dev image (with OB, RB, etc) and at the end I try to run OCompletion tests, the tests takes HOURS. The image seems frozen, but actually is working. If I interrupt I see the problem is in
ECUntypedModel >> initializeSelectors
the part of
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes a lot of time
I know I'm saying this all the time, but it's true: SortedCollection is not suitable for this usage.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My Pharo 1.1 Dev, cog image: OrderedCollection with an initial size of 500 and without sorting, no case sensitive, - 23 seconds OrderedCollection with an initial size of 500 and without sorting, case sensitive, - 17/18 seconds OrderedCollection with an initial size of 500 and sorting with #sortBy:, no case sensitive - 25 seconds OrderedCollection with an initial size of 500 and sorting with #sortBy:, case sensitive - 21 seconds Hope it helps, cheers Guille 2010/9/26 Levente Uzonyi <leves@elte.hu>
On Sun, 26 Sep 2010, Stéphane Ducasse wrote:
On Sep 26, 2010, at 7:03 PM, Levente Uzonyi wrote:
On Sun, 26 Sep 2010, Mariano Martinez Peck wrote:
Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev
image. If I just take a core image, load OCompletion and run tests, they take a lot of time, not acceptable.
7-8 seconds in Squeak using Cog.
and in squeak wihout Cog?
21 seconds.
Levente
Now....if I build a Dev image (with OB, RB, etc) and at the end I try to
run OCompletion tests, the tests takes HOURS. The image seems frozen, but actually is working. If I interrupt I see the problem is in
ECUntypedModel >> initializeSelectors
the part of
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes a lot of time
I know I'm saying this all the time, but it's true: SortedCollection is not suitable for this usage.
Levente
_______________________________________________ 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
Ah, I forgot: SortedCollection no case sensitive -> 58 seconds SortedCollection case sensitive -> 56 seconds On Mon, Sep 27, 2010 at 1:43 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
My Pharo 1.1 Dev, cog image:
OrderedCollection with an initial size of 500 and without sorting, no case sensitive, - 23 seconds
OrderedCollection with an initial size of 500 and without sorting, case sensitive, - 17/18 seconds
OrderedCollection with an initial size of 500 and sorting with #sortBy:, no case sensitive - 25 seconds
OrderedCollection with an initial size of 500 and sorting with #sortBy:, case sensitive - 21 seconds
Hope it helps, cheers
Guille
2010/9/26 Levente Uzonyi <leves@elte.hu>
On Sun, 26 Sep 2010, Stéphane Ducasse wrote:
On Sep 26, 2010, at 7:03 PM, Levente Uzonyi wrote:
On Sun, 26 Sep 2010, Mariano Martinez Peck wrote:
Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev
image. If I just take a core image, load OCompletion and run tests, they take a lot of time, not acceptable.
7-8 seconds in Squeak using Cog.
and in squeak wihout Cog?
21 seconds.
Levente
Now....if I build a Dev image (with OB, RB, etc) and at the end I try to
run OCompletion tests, the tests takes HOURS. The image seems frozen, but actually is working. If I interrupt I see the problem is in
ECUntypedModel >> initializeSelectors
the part of
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes a lot of time
I know I'm saying this all the time, but it's true: SortedCollection is not suitable for this usage.
Levente
_______________________________________________ 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 (3)
-
Guillermo Polito -
Levente Uzonyi -
Stéphane Ducasse