Hi Igor, thanks a lot, your analysis is correct, and it helped.
Am 05.04.2014 um 17:05 schrieb Igor Stasenko: > so, without going deep into implementation details, just by reading comment > i can already see potential bottleneck - using #become: operation which is > veery slow. Yes, #become: is *very* slow in Pharo. No problem at all in VisualWorks or Dolphin Smalltalk or Pharo 1.2, though! Time millisecondsToRun: [1000 timesRepeat: [String new become: String new ]] Pharo 3.0 (and also in 2.0 and 1.4): 3948 3495 2891 2532 3162 Pharo 1.2 with the Squeak 4.2.5beta1U VM: 90 89 82 90 72 VisualWorks 7.9.1: note that this is measured in microseconds: Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]] 211 208 222 212 208 That’s a factor of more than 10.000! IMHO, someone should have a look at the primitives involved. > also, by tracking senders of #knownJavaSubclasses , i see there's also uses > of #become operation.. > > So, my first verdict is: > - excessive use of #become ==> slow performance > :) > > (sure, i have no idea if you can avoid using become or not, but my bet this > is main reason of low performance) Well, given the measurements above, I wouldn’t say that the reason is excessive use of #become:, but the extremely slow implementation of #become: in Pharo since 1.4. However, I managed to remove the need for sending #become: in #findClassFor:, but not in the second place. This reduces the time to start a Java VM to 5-6 seconds on my aged machine (2.4 GHz Intel Core 2 Duo from early 2008). The benchmark which I mentioned in my announcement and which took 12 seconds came down to less than 0.2 seconds. That's a little more than the 0.11 seconds in VisualWorks, but at least in the same order of magnitude. Thanks again! Joachim
