First of all, this is just information and not a request for a firmware change.
Picomite 2350 version 6.01.00.b5
The test was performed on drive B:. Sorting is not performed!

Hi Peter,
while working on the FM (File Manager), I encountered a strange problem. The FM works quite satisfactorily up to about 200 files/folders. Vadim probably rightly limited it for this reason.

In my test version, I increased the possible number to 400 and have about 300 files/directories in the root directory. Sorting by name works satisfactorily, but sorting by date is a pain. Partly, of course, this is due to the simulated Windows/pop-up functions; all data often has to be reread and sorted for a new screen refresh. However, I had the impression that the slowdown wasn't linear, as I would have expected, but increased exponentially with the number of elements (files/folders) to about >3 seconds for 300 elements!

I wanted to know exactly why, so I ran some tests and ultimately wrote a small test program as proof.



The result shows that reading the same amount of data with mm.Info(MODIFIED File$) at a higher position in the array takes significantly longer.




The result is that with 300 elements, the last 10 elements take 50-100 times longer to read mm.Info(MODIFIED FName$) than the first 10 elements. This is probably the main factor, but the length of the file name also has a significant influence. I tested with short names (7 characters) and long names (27 characters). The long names doubled the average read time (FDate$= mm.Info(MODIFIED FName$)), which I don't find unusual.

I assume that MM.INFO(FILESIZE file$) works similarly, but I haven't tested it.

As I said, this all surprised me a bit, and I'm glad to now have an explanation for the behavior in FM. The reason for the behavior of the MM.Info function remains a mystery, however.

Kind regards
Michael
Edited 2025-09-17 08:23 by twofingers