Re: [Pharo-dev] Slowness when loading code in Pharo 7?
On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev < pharo-dev@lists.pharo.org> wrote:
Hi!
I did the same measurement for Pharo 6.1. To summarize it I have those results:
By executing:
-=-=-=- EpMonitor current disable. [ Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. ] timeToRun -=-=-=-
Pharo 6.1 64bit macOS: 6 minutes Pharo 7.0 64bit macOS: 8 minutes
With EpMonitor current enabled it is:
Pharo 6.1 64bit macOS: 7 minutes Pharo 7.0 64bit macOS: 15 minutes
So nice... I was just trying to install GToolkit in P6.1 on Windows (but with updated Iceberg)... it took over 1.5 hours (SmaCC was probably 30 minutes by itself), and then the image crashed... really looking forward to pre-made images :) Peter
On Wed, 2018-10-03 at 20:08 +0200, Peter Uhnak wrote:
On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev <pharo-dev @lists.pharo.org> wrote:
Hi!
I did the same measurement for Pharo 6.1. To summarize it I have those results:Â
By executing:Â
-=-=-=- EpMonitor current disable. [ Metacello new  baseline: 'GToolkit';  repository: 'github://feenkcom/gtoolkit/src';  load. ] timeToRun -=-=-=-
Pharo 6.1 64bit macOS: 6 minutes Pharo 7.0 64bit macOS:Â 8 minutes
With EpMonitor current enabled it is:Â
Pharo 6.1 64bit macOS: 7 minutes Pharo 7.0 64bit macOS: 15 minutes
So nice... I was just trying to install GToolkit in P6.1 on Windows (but with updated Iceberg)... it took over 1.5 hours (SmaCC was probably 30 minutes by itself), and then the image crashed... really looking forward to pre-made images :)
Peter
I ran the attached script on my debian 64 bits (disk: slow HDD w/ext4, cpu: i5 ram: 12gb). Here, the slowdown from 61 to 70 is not as evident as in your cases. It's only me? It can help if others can run the script and report your results in other computers and OSs. Two output examples: --- pharo 61 * disabled: 0:00:07:30.783 * enabled: 0:00:08:27.931 pharo 70 * disabled: 0:00:08:24.403 * enabled: 0:00:09:12.858 --- pharo 61 * disabled: 0:00:08:16.036 * enabled: 0:00:09:21.368 pharo 70 * disabled: 0:00:08:06.57 * enabled: 0:00:10:05.194 --- pharo 61 * disabled: 0:00:07:39.538 * enabled: 0:00:08:33.778 pharo 70 * disabled: 0:00:07:23.528 * enabled: 0:00:09:11.453 --- Note: the script removes pharo-local/ before loading the code to download again everything (and I don't have configured a central repo in personal settings or something like that). It should be more fair to compare to have locally cached as much as possible. I tried once and it was reducing a couple of minutes, but the conclusion was the same. Additionally: In both 61 and 70, I browsed the resulting ombu file (>110 mb), it was not thaat bad... ~5 seconds when I clicked on the file, and then almost no delay on scroll and when clicking on a particular change. But: The problem was when I clicked on a filter and it started to parse each change... I waited like 10 minutes and then closed it. No visual feedback, and looks too inefficient. MartÃn
Hi, In my case I get: pharo 61 * disabled: 0:00:09:39.43 * enabled: 0:00:10:25.173" pharo 70 * disabled: 0:00:12:44.701 * enabled: 0:00:21:21.285 Each time in a clean folder with a new image. All tests are with the current stable vm on High Sierra. Cheers, Andrei On Thu, Oct 4, 2018 at 8:23 AM <tinchodias@gmail.com> wrote:
On Wed, 2018-10-03 at 20:08 +0200, Peter Uhnak wrote:
On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev <pharo-dev @lists.pharo.org> wrote:
Hi!
I did the same measurement for Pharo 6.1. To summarize it I have those results:
By executing:
-=-=-=- EpMonitor current disable. [ Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. ] timeToRun -=-=-=-
Pharo 6.1 64bit macOS: 6 minutes Pharo 7.0 64bit macOS: 8 minutes
With EpMonitor current enabled it is:
Pharo 6.1 64bit macOS: 7 minutes Pharo 7.0 64bit macOS: 15 minutes
So nice... I was just trying to install GToolkit in P6.1 on Windows (but with updated Iceberg)... it took over 1.5 hours (SmaCC was probably 30 minutes by itself), and then the image crashed... really looking forward to pre-made images :)
Peter
I ran the attached script on my debian 64 bits (disk: slow HDD w/ext4, cpu: i5 ram: 12gb). Here, the slowdown from 61 to 70 is not as evident as in your cases.
It's only me? It can help if others can run the script and report your results in other computers and OSs.
Two output examples: ---
pharo 61 * disabled: 0:00:07:30.783 * enabled: 0:00:08:27.931
pharo 70 * disabled: 0:00:08:24.403 * enabled: 0:00:09:12.858
---
pharo 61 * disabled: 0:00:08:16.036 * enabled: 0:00:09:21.368
pharo 70 * disabled: 0:00:08:06.57 * enabled: 0:00:10:05.194
---
pharo 61 * disabled: 0:00:07:39.538 * enabled: 0:00:08:33.778
pharo 70 * disabled: 0:00:07:23.528 * enabled: 0:00:09:11.453
--- Note: the script removes pharo-local/ before loading the code to download again everything (and I don't have configured a central repo in personal settings or something like that). It should be more fair to compare to have locally cached as much as possible. I tried once and it was reducing a couple of minutes, but the conclusion was the same.
Additionally: In both 61 and 70, I browsed the resulting ombu file (>110 mb), it was not thaat bad... ~5 seconds when I clicked on the file, and then almost no delay on scroll and when clicking on a particular change.
But: The problem was when I clicked on a filter and it started to parse each change... I waited like 10 minutes and then closed it. No visual feedback, and looks too inefficient.
MartÃn
participants (3)
-
Andrei Chis -
Peter Uhnak -
tinchodias＠gmail.com