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