Messages in this thread | | | Date | Mon, 8 Mar 1999 18:30:51 +0200 (EET) | From | Jukka Tapani Santala <> | Subject | Re: FAT speedup patch revisited for 2.2.1 |
| |
On Sun, 7 Mar 1999, Riley Williams wrote: > I'll agree that systems running MS-DOS 1.xx are probably not in the > majority, but that's the only variation from that specification that I > am aware of...
Actually, a nul-termination doesn't matter in the extension bit, as this will just lead to few more nulls at the end of the filename, which get skipped. I'm not sure if it'd make difference with long filenames, but somehow I suspect there aren't many MS-DOS 1.xx VFAT-setups out there...
Anyway, there's another "problem" now, altough I've rewritten the actual copy-over code in fat_readdirx() about as fast as it goes, the problem is that it seems to change the code placement and optimizations in subtle ways causing the rest of the function, unchanged, get dirt-poor performance at least on -O2.
The whole fat_readdirx() function is actually an optimizers nightmare, consisting of over 200 lines of deeply nested code. I've tried breakign it up to parts a few times, without success, as the different parts are dependent on so much state-information. Perhaps if I manage to optimize the rest of the code, too, at least that will change the code arrangement and possible optimization results.
Ofcourse, there's a philosophical question, if you write bit of source as fast as it can go, and then the compiler/optimizer messes it up making it slower, is it still better? Oh well. The bit-shift part of the patch does speed things up currently (On ALPHA it may not, I'm told, but how many people use *FAT on ALPHA?) but the changes to fs/fat/dir.c lead to slower overall performance, 'though the optimized part flies.
-Donwulff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |