Le dim. 29 déc. 2019 à 23:35, tim Rowledge <tim at rowledge.org> a écrit :

>
>
> > On 2019-12-29, at 12:45 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > That's not a valid comparison.  You're looking at a small machine with a
> very small file system.  You need o run it on a large machine with a very
> full filesystem.  The time taken isn't dependent on the speed of the
> machine, but dominated by the amount of files and directories examined.
>
> Mmm... ok, the file directory scanning for the tree view is certainly
> horribly horrible. The most complex one I have to hand is my iMac, using an
> image within a bundle; that's a bunch of layers down in some relatively big
> directories and is essentially instant.
>
> The current algorithm for generating the directory tree does some
> extraordinary hoop-jumping that must surely be improvable.
>  - it gets a listing of the root directory's subdirectories and wraps each
> one in a complex Morph
>  - it builds a list of the directories in the path to the current image
> directory keeping the full pathname of each for some reason
>  - it finds the first root directory subdirectory morph and scans from
> there through its siblings to find the first one with a name suitably
> matching the first thing in the above directory pathname list
>  - which it expands
>  - which causes it to list all the subdirectories  and so on until the
> list of directory pathnames is exhausted
>
> So at least it doesn't read the name and path of every file in the entire
> universe.
> It *does* add in the names of any cached known servers (which I've
> mentioned several times is very out of date and in need of flushing). It
> does use the possibly wasteful FileDirectory>>#directoryNames that reads
> every name in the directory and test every one for directory-ness; surely
> there are faster approaches for most OSs? It does rely on assumptions about
> root directories, which we can blame on the generally inadequate filesystem
> code. Some OS (I'm giving you the stink-eye here, Windows 10) having very
> strange ideas about directory layouts and names and so forth.
>
> I hope it does not ask anymore to insert a floppy in drive A: ;)

A very deep directory tree above your image directory will add time, as
> will any of those directories being very large. We could certainly design a
> faster approach to building a useful directory display for the typical
> purposes a FileDialog is useful for; the current one simply reuses the
> stuff in the FileBrowser.
>
> But I claim that for occasional use UI such as finding a new place/name to
> save you image, or your preferences, or  whatever, that anything less than
> half a second is effectively instant to human perception. Unless perhaps
> you are a dyed in the wool twitch-gamer with perceptual reflexes tuned to
> microseconds in preparation for being beamed up by the alien visitors that
> need your mind to fight a galactic war.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Klingon Code Warrior:- 2) "My program has just dumped Stova Core!"
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191229/9851ddf0/attachment.html>