Faster built-in filemanager?
 

I wonder if OS2008 has a faster built-in filemanager. In OS200x < 8 it was very slow and inresponsive while opening folders with a lot of subfolders and/or files therein. I guess it analyzes file types or caches file infos recursively. For instance, I have a folder with about 40 subfolders each containing about 50 pictures. It takes more than 10 seconds until I can select a subfolder once I opened this folder, even without thumbs previews. The same happens with file open dialogues (probably for the same but unknown reason). Maybe that's influenced by metalayer-crawler (which I have completely disabled) or not. How does the new filemanager behave? Does anyone know how to speed it up? BTW None of the others (mc, gpe,...) is an alternative for me so far.

Re: Faster built-in filemanager?
 

this should be a useful thread, i'll do a little digging soon

Re: Faster built-in filemanager?
 

First off, SD cards are slow. Secondly, we have a slow processor. Lots of files and folders is going to make it slow. Turning off metalayer-crawler won't change that.

Re: Faster built-in filemanager?
 

Well, that's definitely not the source of the problem. Canoe ( http://maemo.lancode.de/?path=./binary-bora ) is as fast as a filemanager should be. No delay at all when opening deep folders with lots of files. Same for midnight commander mc. I wonder whether others do not suffer like me with this...

Re: Faster built-in filemanager?
 

Hm.. I think I have to agree with gammer here. The cards aren't that slow. FileZ on my Palm (which isn't fast with cards) is lightning fast when walking up and down SD card directories.
I did a little test with my old 1GB SD card on my N800.
find /media/mmc1 | wc -l
shows 1840 files and directories.
Then open the card door, close it (to re-mount the card, which will flush any memory buffers that would artificially speed up the process). Then measure how long it takes to read every file entry in every directory:
time ls -lR /media/mmc1 > /dev/null
real 0m 2.71s
user 0m 0.30s
sys om 1.96s

Quite fast..
gammer, you could try the same excersize with your particular card. That would give you an idea of how fast it could be done.
Of course, the file manager does much more - if there are pictures it'll thumbnail them and so on. Which means that it'll have to read at least the beginning of every file, not just file entries, just to classify them.

Re: Faster built-in filemanager?
 

For 12667 files and directories on my 4GB transcend SD I get
real 0m 20.89s
user 0m 1.12s
sys 0m 11.68s
This is acceptable, but I think a filemanager would not go as deep as possible in every situation. Time until subdirectories become "available" in the built-in filemgr obviously depends on the contents of those subdirs. If I do your experiment with the aforementioned pictures folder then I get for 1457 files and directories
real 0m 1.06s
user 0m 0.18s
sys 0m 0.54s
But opening it with the filemgr is really annoying, with and without thumbnail previews! If I could switch off the more or less useless look-ahead-feature (or whatever it is) then I could save a lot of time each day.

Re: Faster built-in filemanager?
 

BTW my hope was that the new OS2008 filemanager performs better. Does it?

Re: Faster built-in filemanager?
 

IME, yes and no.

It still has notable (and imo unacceptable) interface lag/locks when browsing large directories in the non-thumbnail view.

Yet, oddly, it's far and away more responsive when browsing a folder of images with thumbnails enabled. Even though it takes longer for the thumbnails to fully populate, the list of files itself appears at least twice as fast. (and often, faster)
And I can navigate away from an errant selection much sooner than if I had thumbnails disabled.

I have a large number of reference images on the 'internal' SD card in a large number of category sub-folders. A simple subfolder mis-click can effectively lock my device for ~1 second per hundred images without thumbnails. And that gets frustrating fairly quickly (particularly when combined with the still-not-finger-friendly file manager interface).

With thumbnails? It's more like a half or third of a second per hundred.

If nothing else, they need to code the non-thumbnail view to remain responsive while building the list of files in a directory.

Re: Faster built-in filemanager?
 

And as a bonus on 2008 the TCP/IP stack is integrated in file manager and it will show wireless network shares. < This is the only slowness mine exhibits but that may have more to do with network communication speed.

However, I don't go very deep with device directories and I suspect mileage will vary.

Re: Faster built-in filemanager?
 

Maybe the title of this thread is too specific. I experience the same delays as well in file open dialogs for such "richer" directories (for instance with the Mirage picture viewer from Garage, which is in Python). There seem to be some system calls used by filemanager and such dialogs to explore directory content. The lag may result from the analysis of file type and/or assigment of icons or handlers for opening the file under inspection or whatever. The truth is in the code, so either a developer could give an answer or one has to study the APIs. For me it would be a tremendous improvement to speed up these dialogs and in particular the filemanager on "rich" directories. It's a real show stopper when I demonstrate my wonderful N800 to others by navigating through my pics collection, but then I have to wait 5 seconds before I can enter another folder for the first time. I'm thinking of filing a bug in Maemo's bugzilla.