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