Looks like some changes of ECompletion are then missing in OCompletion. ECompletion doesn't use Preferences for a long time anymore.
Lukas On 28 September 2010 02:26, Henrik Sperre Johansen <[email protected]> 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" ;) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
