Hi Cyril, On Tue, 12 Feb 2019 at 11:57, Cyril Ferlicot <cyril.ferli...@gmail.com> wrote: > > On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant <akgrant0...@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
