[Pharo-dev] File problems in Pharo 8

Alistair Grant akgrant0710 at gmail.com
Wed Feb 13 02:03:41 EST 2019


Hi Cyril,

On Tue, 12 Feb 2019 at 19:41, Cyril Ferlicot D.
<cyril.ferlicot at gmail.com> wrote:
>
> Le 12/02/2019 à 18:56, Alistair Grant a écrit :
> > Hi Cyril,
> >
> > ...
> >
> > However any application that iterates over a large number of files could
> > well be slower because the Guide / Visitor system retrieves entries.
> >
>
> Thank you for the detailed explanation!
>
> > Do you know how many files are being deleted when the system feels
> > slower?
>
> I was committing in Iceberg that is a Filetree repository. My change
> impacted multiple package thus I would say it should be around 2500
> files and 500 folders.

I wrote a class to measure the time taken by the Visitor / Guide -
it's basically the same as the DeleteVisitor but just counts the
number of files visited.  Running this on a directory that contains
82331 files including 10169 directories.   My 6 year old Dell XPS 13
(i7, SSD, 8G RAM) gives the following average times:

Pharo 7: 3.7 seconds
Pharo 8: 2.6 seconds

I've attached the class below.

> > It would be straightforward to modify the directory iteration primitives
> > to only answer the file name instead of all attributes.  I'll have a
> > look and see how easy it would be to modify the Guide / Visitor objects
> > to retrieve only file names instead of entire entries.
> >
>
> So if possible it would make file copy/deletion even faster than before
> IIUC? That would be really great!

The Guide / Visitor framework uses file attributes to navigate the
tree, so retrieving only file names wouldn't be useful.

But I did notice that the entries weren't being initialised properly,
so after fixing that bug the average run time for Pharo 8 drops:

Pharo 8: 1.7 seconds

I'll submit a PR with this fix.

I also realised I inadvertently changed the behaviour of DeleteVisitor
slightly.  In Pharo 7 the Visitor will descend in to a symbolic link
that points to a directory, in Pharo 8 it doesn't.  This prevents the
system from entering an infinite loop if the symbolic link points to
the directory containing the link, but means that the set of files
visited may be different.  Pharo 7 may visit additional files that are
currently skipped by Pharo 8, or it may visit some multiple times.
I'll raise this as a separate discussion as I'm not sure that simply
reverting to the old behaviour is a good idea.

Cheers,
Alistair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AKG-Visitors.st
Type: application/octet-stream
Size: 1780 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190213/d60f939b/attachment.st>


More information about the Pharo-dev mailing list