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
