Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
mariano can you open a bug entry. Stef On Sep 26, 2010, at 6:21 PM, 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.
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
and it seems related to "ECPreferences caseSensitive" and "ECUntypedModel >> resetSelectors"
I don't know what else to say. To reproduce, take a PharoCore 1.1 and evaluate:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load.
(ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests'
Then, run all the tests inside OCompletionTests. You will see that after running some threads....it will look like frozen. There, do an interrupt and analize.
IF you do that for a Dev image, it takes muuuuch more. I guess this is because "Smalltalk environment keys" will have muuuuuch more elements than a simple core.
Anyway, help is appreciated.
Cheers
Mariano _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In a plain ECompletion image the code
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes around 30 milliseconds to evaluate. Lukas On 27 September 2010 16:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mariano can you open a bug entry.
Stef On Sep 26, 2010, at 6:21 PM, 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.
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
and it seems related to  "ECPreferences caseSensitive"  and "ECUntypedModel >> resetSelectors"
I don't know what else to say. To reproduce, take a PharoCore 1.1 and evaluate:
Gofer new   squeaksource: 'MetacelloRepository';   package: 'ConfigurationOfOCompletion';   load.
(ConfigurationOfOCompletion project version: '1.2') load: Â 'Core Tests'
Then, run all the tests inside OCompletionTests. You will see that after running some threads....it will look like frozen. There, do an interrupt and analize.
IF you do that for a Dev image, it takes muuuuch more. I guess this is because "Smalltalk environment keys" will have muuuuuch more elements than a simple core.
Anyway, help is appreciated.
Cheers
Mariano _______________________________________________ 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
-- Lukas Renggli www.lukas-renggli.ch
IF you take a 1.1 core and just load OCompletion: MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 If you load OCompletion and the rest of the dev image: MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 However, IN pharo dev 1.0 it is MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 sooo.... ???? something has changed? cheers Mariano On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli@gmail.com> wrote:
In a plain ECompletion image the code
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes around 30 milliseconds to evaluate.
Lukas
On 27 September 2010 16:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mariano can you open a bug entry.
Stef On Sep 26, 2010, at 6:21 PM, 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.
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
and it seems related to "ECPreferences caseSensitive" and "ECUntypedModel >> resetSelectors"
I don't know what else to say. To reproduce, take a PharoCore 1.1 and evaluate:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load.
(ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests'
Then, run all the tests inside OCompletionTests. You will see that after running some threads....it will look like frozen. There, do an interrupt and analize.
IF you do that for a Dev image, it takes muuuuch more. I guess this is because "Smalltalk environment keys" will have muuuuuch more elements than a simple core.
Anyway, help is appreciated.
Cheers
Mariano _______________________________________________ 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
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage. If you have n classes in the system, the method takes O(n^2) time. I have already fixed this, though it's not available yet. Using the Pharo 1.1 OneClick image I get these values for [ECContextTest new testUntypedVarsOnly] timeToRun : Old: 28227 New: 1241 Levente
cheers
Mariano
On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli@gmail.com> wrote:
In a plain ECompletion image the code
[ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes around 30 milliseconds to evaluate.
Lukas
On 27 September 2010 16:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mariano can you open a bug entry.
Stef On Sep 26, 2010, at 6:21 PM, 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.
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
and it seems related to "ECPreferences caseSensitive" and "ECUntypedModel >> resetSelectors"
I don't know what else to say. To reproduce, take a PharoCore 1.1 and evaluate:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load.
(ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests'
Then, run all the tests inside OCompletionTests. You will see that after running some threads....it will look like frozen. There, do an interrupt and analize.
IF you do that for a Dev image, it takes muuuuch more. I guess this is because "Smalltalk environment keys" will have muuuuuch more elements than a simple core.
Anyway, help is appreciated.
Cheers
Mariano _______________________________________________ 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
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
If you have n classes in the system, the method takes O(n^2) time. I have already fixed this, though it's not available yet.
let us know when this is available.
Using the Pharo 1.1 OneClick image I get these values for [ECContextTest new testUntypedVarsOnly] timeToRun : Old: 28227 New: 1241
Levente
cheers
Mariano
On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli@gmail.com> wrote:
In a plain ECompletion image the code
[ Smalltalk environment keysDo:
[ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes around 30 milliseconds to evaluate.
Lukas
On 27 September 2010 16:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mariano can you open a bug entry.
Stef On Sep 26, 2010, at 6:21 PM, 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.
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
and it seems related to "ECPreferences caseSensitive" and
"ECUntypedModel >> resetSelectors"
I don't know what else to say. To reproduce, take a PharoCore 1.1 and
evaluate:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load.
(ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests'
Then, run all the tests inside OCompletionTests. You will see that after
running some threads....it will look like frozen. There, do an interrupt
and analize.
IF you do that for a Dev image, it takes muuuuch more. I guess this is
because "Smalltalk environment keys" will have muuuuuch more elements
than a simple core.
Anyway, help is appreciated.
Cheers
Mariano _______________________________________________ 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
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ 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
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code.
If you have n classes in the system, the method takes O(n^2) time. I have already fixed this, though it's not available yet.
let us know when this is available.
A preview version is available here: http://leves.web.elte.hu/squeak/Ocompletion-ul.77.mcz It should work in Pharo 1.1, though it has some additional Squeak specific code which is unnecessary for Pharo. Levente
Using the Pharo 1.1 OneClick image I get these values for [ECContextTest new testUntypedVarsOnly] timeToRun : Old: 28227 New: 1241
Levente
cheers
Mariano
On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli@gmail.com> wrote:
In a plain ECompletion image the code
[ Smalltalk environment keysDo:
[ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ].
takes around 30 milliseconds to evaluate.
Lukas
On 27 September 2010 16:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mariano can you open a bug entry.
Stef On Sep 26, 2010, at 6:21 PM, 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.
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
and it seems related to "ECPreferences caseSensitive" and
"ECUntypedModel >> resetSelectors"
I don't know what else to say. To reproduce, take a PharoCore 1.1 and
evaluate:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load.
(ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests'
Then, run all the tests inside OCompletionTests. You will see that after
running some threads....it will look like frozen. There, do an interrupt
and analize.
IF you do that for a Dev image, it takes muuuuch more. I guess this is
because "Smalltalk environment keys" will have muuuuuch more elements
than a simple core.
Anyway, help is appreciated.
Cheers
Mariano _______________________________________________ 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
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ 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
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup. Cheers, Henry
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :) Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences... Cheers, Henry
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times. Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 28.09.2010 01:43, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times.
Levente Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;)
Cheers, Henry
Looks like some changes of ECompletion are then missing in OCompletion. ECompletion doesn't use Preferences for a long time anymore. Lukas On 28 September 2010 02:26, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
 On 28.09.2010 01:43, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
 IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] Â 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] Â 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? Â did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code.
TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente
Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times.
Levente
Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;)
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 01:43, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times.
Levente Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;)
30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick image has 3220 globals. The sortBlock asks for the preference twice per evaluation. SortedCollection uses a binary search during #add:. If we are optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times which is ~75k. In the same image the "old" code asked for the preference 2282899 times during the tests, while the new code did it only 398 times. If the preference is changed to return the value of a variable, then the difference is only 80 ms, otherwise it's 36.6 seconds. Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks to everybody. I did what you say and now MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023 I've just commited OCompletion. And I didn't know TimeProfiler :) cheers Mariano On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 01:43, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code.
TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente
Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times.
Levente
Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;)
30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick image has 3220 globals. The sortBlock asks for the preference twice per evaluation. SortedCollection uses a binary search during #add:. If we are optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times which is ~75k.
In the same image the "old" code asked for the preference 2282899 times during the tests, while the new code did it only 398 times. If the preference is changed to return the value of a variable, then the difference is only 80 ms, otherwise it's 36.6 seconds.
Levente
Cheers, Henry
_______________________________________________ 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
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote:
Thanks to everybody. I did what you say and now
MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023
I've just commited OCompletion.
And I didn't know TimeProfiler :)
If you download http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get better results: [ ECContextTest new testUntypedVarsOnly ] timeToRun "===> 815" Levente
cheers
Mariano
On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 01:43, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code.
TimeProfiler to the rescue: Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente
Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times.
Levente
Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;)
30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick image has 3220 globals. The sortBlock asks for the preference twice per evaluation. SortedCollection uses a binary search during #add:. If we are optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times which is ~75k.
In the same image the "old" code asked for the preference 2282899 times during the tests, while the new code did it only 398 times. If the preference is changed to return the value of a variable, then the difference is only 80 ms, otherwise it's 36.6 seconds.
Levente
Cheers, Henry
_______________________________________________ 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
On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote:
Thanks to everybody. I did what you say and now
MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023
I've just commited OCompletion.
And I didn't know TimeProfiler :)
If you download http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get better results:
[ ECContextTest new testUntypedVarsOnly ] timeToRun "===> 815"
Excellent. Thanks Levente
Levente
cheers
Mariano
On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 01:43, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:41, Levente Uzonyi wrote:
On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
On 28.09.2010 00:07, Levente Uzonyi wrote:
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
2010/9/27 Levente Uzonyi <leves@elte.hu>
On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
IF you take a 1.1 core and just load OCompletion:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
If you load OCompletion and the rest of the dev image:
MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
However, IN pharo dev 1.0 it is
MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
sooo.... ????
something has changed?
As I said, SortedCollection is not suitable for this kind of usage.
But in Pharo 1.0 OCompletion was doing the same....so? did SortedCollection chang between 1.0 and 1.1?
No, something else changed. The same test is still 5x faster in 1.0 dev with the new code.
TimeProfiler to the rescue:
Preferences class >> ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms)
Preference>>settingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup.
Nice find. If you check my code, you'll find that I optimized that away. :)
Levente
Yes ,you moved it out of the actual sort loop :)
Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance.
IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences...
The preferences should be updated, but sending a message once is still better than 2k-30k times.
Levente
Sure, on the order of a couple of milliseconds difference.
I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;)
30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick image has 3220 globals. The sortBlock asks for the preference twice per evaluation. SortedCollection uses a binary search during #add:. If we are optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times which is ~75k.
In the same image the "old" code asked for the preference 2282899 times during the tests, while the new code did it only 398 times. If the preference is changed to return the value of a variable, then the difference is only 80 ms, otherwise it's 36.6 seconds.
Levente
Cheers,
Henry
_______________________________________________ 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 (5)
-
Henrik Sperre Johansen -
Levente Uzonyi -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse