Hi, In Pharo 8 I have troubles because I get an error each time I try to do an action calling a #deleteAll. I think the problem might have been introduced by the changes on Files that were done to introduce FIleAttributes. I don't have much knowledge on this area and this is a little blocking for me because when the problem triggers I cannot commit my changes with Iceberg since it needs to delete folders. Bug report: https://github.com/pharo-project/pharo/issues/2495 -- Cyril Ferlicot https://ferlicot.fr
Hi Cyril, In not at my PC at the moment, sorry. Can you try with vmLatest80? curl get.pharo.org/64/vmLatest80 | bash This looks like an issue I resolved recently. Cheers, Alistair (on phone) On Tue., 12 Feb. 2019, 11:16 Cyril Ferlicot, <cyril.ferlicot@gmail.com> wrote:
Hi,
In Pharo 8 I have troubles because I get an error each time I try to do an action calling a #deleteAll.
I think the problem might have been introduced by the changes on Files that were done to introduce FIleAttributes.
I don't have much knowledge on this area and this is a little blocking for me because when the problem triggers I cannot commit my changes with Iceberg since it needs to delete folders.
Bug report: https://github.com/pharo-project/pharo/issues/2495
-- Cyril Ferlicot https://ferlicot.fr
On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Cyril,
In not at my PC at the moment, sorry.
Can you try with vmLatest80?
curl get.pharo.org/64/vmLatest80 | bash
This looks like an issue I resolved recently.
I can commit with this vm. Thank you. I have the impression that the commit takes longer now but I don't have any bench. (maybe it's just my imagination).
Cheers, Alistair (on phone)
-- Cyril Ferlicot https://ferlicot.fr
Hi Cyril, On Tue, 12 Feb 2019 at 11:57, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Cyril,
In not at my PC at the moment, sorry.
Can you try with vmLatest80?
curl get.pharo.org/64/vmLatest80 | bash
This looks like an issue I resolved recently.
I can commit with this vm. Thank you.
I'm glad you're able to commit now. :-)
I have the impression that the commit takes longer now but I don't have any bench. (maybe it's just my imagination).
A few comments on the performance: I haven't done a performance comparison for a while, and there have been a few changes in the plugin, so I'll keep it qualitative for now and try and run some more tests soon. FileReference>>exists should be significantly faster than before. It used to retrieve all the file attributes (an array of values, mostly integers and booleans). Now it just returns a boolean. Retrieving individual file attributes should also be faster. E.g. FileReference>>modificationTime also retrieved all file attributes and threw away everything except the desired attribute. Now it answers just the requested attribute. Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit slower because more information is being retrieved than previously. FileReference>>exists gets called a lot. So do requests for individual file attributes. So my perception was that overall the system would probably be a bit faster than previously. However any application that iterates over a large number of files could well be slower because the Guide / Visitor system retrieves entries. Do you know how many files are being deleted when the system feels slower? 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. Cheers, Alistair
Le 12/02/2019 à 18:56, Alistair Grant a écrit :
Hi Cyril,
I'm glad you're able to commit now. :-)
A few comments on the performance:
I haven't done a performance comparison for a while, and there have been a few changes in the plugin, so I'll keep it qualitative for now and try and run some more tests soon.
FileReference>>exists should be significantly faster than before. It used to retrieve all the file attributes (an array of values, mostly integers and booleans). Now it just returns a boolean.
Retrieving individual file attributes should also be faster. E.g. FileReference>>modificationTime also retrieved all file attributes and threw away everything except the desired attribute. Now it answers just the requested attribute.
Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit slower because more information is being retrieved than previously.
FileReference>>exists gets called a lot. So do requests for individual file attributes. So my perception was that overall the system would probably be a bit faster than previously.
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.
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!
Cheers, Alistair
-- Cyril Ferlicot https://ferlicot.fr
Hi Cyril, On Tue, 12 Feb 2019 at 19:41, Cyril Ferlicot D. <cyril.ferlicot@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
Alistair Grant wrote
I⦠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.
Thank goodness someone finally fixed that! IMHO the old behavior was extremely dangerous and I greatly limited my use of #deleteAll for that reason. '/path/to/aFolder' deleteAll where - aFolder - aSymbolicLinkTo~ No problem, we all have backups, right?... right? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
participants (4)
-
Alistair Grant -
Cyril Ferlicot -
Cyril Ferlicot D.
-
Sean P. DeNigris