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