Issue 5880 in pharo: FileBrowser is slow when directory has lot of entries

Status: Accepted
Owner: [hidden email]
Labels: Type-Enh

New issue 5880 by [hidden email]: FileBrowser is slow when directory  
has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

For example, try to browse your package-cache

For each entry, the full directory is scanned again just to answer if the  
entry is a directory...



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixReviewNeeded

Comment #1 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

Attached a changeSet to correct this...



Attachments:
        DiskStore-nodeAtifPresentifAbsent.st  743 bytes


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #3 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

we have to test this under unix / win, I think I fixed and implemented the  
primitives under OSX.

otherwise => READY TO GO!


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

Note that the fix makes things better...
But it's not sufficient:
- 46seconds in pharo
- vs 3seconds in Squeak old and dirty FileList,
same VM, same repository...
I still prefer the dirty one - as long as I don't have to modify it ;)

We should think of caching the low level information while sorting.
Otherwise, we query the system primitives too much...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

And a perfect generic answer is developped here
http://objology.blogspot.com/2012/05/tag-memoizedfunctions.html


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

Two points/questions:
      is the speed of the squeak version due to its hackish nature?

Nicolas I think that we could subclass BlockClosure that support  
memorization as we did for once support.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

in 20082


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Integrated

Comment #8 on issue 5880 by [hidden email]: FileBrowser is slow when  
directory has lot of entries
http://code.google.com/p/pharo/issues/detail?id=5880

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker