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

Mariano Martinez Peck marianopeck at gmail.com
Fri Oct 1 04:37:38 EDT 2010


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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101001/a1402d9d/attachment-0001.html>


More information about the Pharo-dev mailing list