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

Attachment: timeToRun.sh
Description: application/shellscript

Reply via email to