[Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

Mariano Martinez Peck marianopeck at gmail.com
Fri Oct 1 06:11:38 EDT 2010


On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi <leves at 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 at 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 at 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 at lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>  _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101001/decca613/attachment-0001.html>


More information about the Pharo-dev mailing list