Closed bfis closed 8 years ago
Thanks for the report!
I'm not surprised this is an issue for big directories; we stat all the files to determine if they're a folder or not, and we don't cache between path changes (meaning every time you type it resets). Then we shove it all in the DOM at once.
I can see a view needed improvements:
Points 2 and 3 have been implemented as part of a rewrite of the view code in React. See https://github.com/Osmose/advanced-open-file/commit/12517c1f44f5428bb760e48385a88b99b57d3ce7 and https://github.com/Osmose/advanced-open-file/commit/806d5879000ec2b4212b843be6fc21699c999376.
I tested locally using a directory with 10k files and found that listing times fell from 4-5 seconds to 1-2 seconds. Scroll performance seems to be better as well. I'm still messing around with making file operations async for $56, which should also help, and I think there's room for improvement in the sorting and path comparison phases of listing files as well.
I've released these changes as part of the 0.15.0 release and am closing this issue. Can you upgrade and report back whether you see an improvement? If you don't, we can reopen and keep digging. Thanks!
There should be a setting to limit the number of entries in the listing shown. The list can simply be cut off a the user defined point. Maybe an ellipsis can be added to show that there are more entries.
I would need this since I have some folders with lots of files (10000+) and the listing takes about 5 seconds to show. This occurs every time the listing is show, even when it was already shown (started typing in a filename and then erased it again). I sincerely doubt that this is a filesystem performance issues since the folders are on an SSD and a listing of them in other application has no delay.