On Fri, Dec 22, 2017 at 9:40 AM, Andreas Brodbeck <da...@mindclue.ch> wrote:
> Am 19.12.17 um 11:40 schrieb Andreas Brodbeck: > > Am 18.12.17 um 20:45 schrieb Henrik-Nergaard: > > > > So: It's not the storage! It's something inside Fuel. I keep > > investigating and will update here. > > ... so here are my latest findings: > > I took both images onto the same machine, a Mac. And these are the > differences of the same Fuel serialization: > > ********************* > Fuel 2.1.10 Pharo 6.1 (#60520) 64bit: 90 seconds > Fuel 2.1.10 Pharo 6.1 (#60527) 32bit: 245 seconds > ********************* > > For the record, here the versions of the two (equal) VMs: > > VM 32bit: 5.0 5.0.201707201942 Mac OS X built on Jul 20 2017 21:45:23 > UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) > [Production Spur VM] > > VM 64bit: 5.0 5.0.201707201942 Mac OS X built on Jul 20 2017 21:08:05 > UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) > [Production Spur 64-bit VM] > > > > I didn't expect the 64bit version to be a faster VM generally. What > could be the reason here? > > We have a special cluster for numbers that when they fit there, the serialization is faster (see #clusterClassForSmallInteger:). If bigger than the allowed range then it follows the slower kind of variable/indexed object. Another possibility could be Floats. Can you check in your debug if you have a cluster (FLSmallIntegerCluster subclass ) with MANY numbers? Else, check with many floats.. I think it should be somehow related to that... Cheers, > > Cheers, Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > > -- Mariano http://marianopeck.wordpress.com
