ECompletion/OCompletion tests takes A LIFE!!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: ECompletion/OCompletion tests takes A LIFE!!

Mariano Martinez Peck
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 <[hidden email]> 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 <[hidden email]>

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
[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
Reply | Threaded
Open this post in threaded view
|

Re: ECompletion/OCompletion tests takes A LIFE!!

Levente Uzonyi-2
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 <[hidden email]> 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 <[hidden email]>
>>>>>>>>>
>>>>>>>>>  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
>>> [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
Reply | Threaded
Open this post in threaded view
|

Re: ECompletion/OCompletion tests takes A LIFE!!

Mariano Martinez Peck


On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>

 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
[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
12