Hi John, On Tue, Jun 21, 2016 at 1:30 PM, John Brant <[email protected]> wrote:
> On 06/21/2016 08:13 AM, Sven Van Caekenberghe wrote: > >> >> On 21 Jun 2016, at 11:58, Ben Coman <[email protected]> wrote: >>> >>> On Tue, Jun 21, 2016 at 3:29 PM, Clément Bera <[email protected]> >>> wrote: >>> >>>> Hello John. >>>> >>>> I'm just guessing here. Lacking information. It could be: >>>> >>>> Guess 3) the UI is known to be much slower in Pharo. Can you try >>>> headless or >>>> after ticking "Server mode" In the Pharo settings in System. >>>> >>> >>> Or try something like... >>> [ Transcript cr; show: (Time millisecondsToRun: [1 to: 100000000 do: >>> [:i | Object new]] ) ] forkAt: 75. >>> >> >> BTW, this is essentially a garbage collection benchmark: you create >> 100,000,000 empty objects. It stresses the GC, especially the ephemeral >> phase of it. Since the GC is part of the VM, you are testing the VM more >> than any image code. >> > > That's what I thought too, and that's why I was surprised that there was > much difference between Squeak and Pharo for this. Furthermore, when I ran > the Pharo image using a Squeak vm, I still saw the difference so I thought > it must be some image related thing instead of a vm. FYI, the differences between the VMs are minimal. The base VMs differ only in the FilePlugin API, such that the Pharo API supports accessing POSIX file permissions whereas the Squeak one does not. There are differences in the set of external plugins, Pharo providing Freetype and Cairo support, whereas buy default the Squeak VM does not. But in the execution machinery they are identical. So it's a relief to me that you've pin-pointed a UI issue. That makes sense to me, whereas, say, differences in GC performance due to finalisation load would confuse me as I see no likely cause of the size of effect you're seeing. HTH John Brant > _,,,^..^,,,_ best, Eliot
