On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
