Great Performance from FullFAT
Under General Discussion
Discuss, 2 Comments.
Follow any responses to this entry through the RSS 2.0 feed.
Posted on Monday, November 17th, 2008 at 8:47 pm
Under General Discussion
Discuss, 2 Comments.
Follow any responses to this entry through the RSS 2.0 feed.
Posted on Monday, November 17th, 2008 at 8:47 pm
Today I managed to find some time to test the performance of FullFAT so far. (Always good to know your heading in the right direction).
I got some very promising results, testing on BlackFIN hardware, in comparison to a port of the FreeDOS fat driver:
The performance shows figures, for directory tree traversal using long filenames.
FreeDOS took 232982011 Core Clock Cycles.
FullFAT took only 3357211 Core Clock Cycles.
That shows that the FullFAT algorithm for directory tree traversal, and long-filename handling is 70x faster.
The test involved invoking the ls command, and seeing how long it took, using each driver.
I’ve also improved the portability of the entire framework, by ensuring that there are no memory alignment issues. The only platform portability that is required is to create memory access routines for BIG ENDIAN devices, and also those devices that do not have single byte access.
All these options will be easily configurable in a config.h header file.
These results surprised me a little, as I thought my directory tree traversal algorithm wasn’t particularly lean, I’ll see if I can improve even further later. Right now, stability across all platforms is the main priority.
The next small task is to bring FAT32 compatibility in-line with FAT16. Then i’ll be traversing the FAT tables, and reading files as efficiently as possible.
I’ll write more at a later date to keep you informed with the progress.
© 2009 James Walmsley. All rights reversed. Contact us.
12-Dec-08
Interesting work on the FAT16/FAT32 driver. Do you have any idea about codesize RAM/FLASH ?
Regards,
Mattias
13-Jan-09
Well there’s no exact values on codesize, memory footprint, as I’m still at an early stage of development.
I’m constantly optimising my work in these areas, checking memory footprint etc.
It will be very small.
FullFAT in its current state can utilise very little memory, or as much as can be made available to it.
There’s a tiny memory manager, which handles buffers in a thread-safe way, the minimum memory this uses is 512 bytes, (1 block). Although I’m not too sure how it will perform with such a constraint.
I shall add more details as soon as I can. Take a look around February for a release.