Nobin Mathew <nobin.mathew@xxxxxxxxx> writes: > Library using mmap() for creating buffer is not clear, I don’t know > why it uses mmap(), may be to give more guaranteed file open (I think > mmap() will be more successful than malloc() during system load) or > not to eat up process heap when large number of files are open, but > this approach by default(when setvbuf() is not used) reduces program > performance. > > Why this mmap approach is used? Is there any way other > than setvbuf/setbuf and direct IO to avoid minor pagefaults. This is not a gcc question at all. glibc is a separate project with its own mailing lists. If you want to know why glibc is doing something, you need to ask the glibc developers. See http://sourceware.org/glibc/ . That said, using mmap to allocate a page to use for a FILE* buffer seems quite reasonable to me. Yes, there will be an initial page fault, but so what? Most FILEs are used for a sequence of I/O, and that page fault won't count for much. The FILE structure is intended to be efficient when used with getchar and putchar, so the buffering is important for good performance. A program like yours, which does only large freads, is not the case for which FILE is optimized. Your program would be faster, albeit slightly less portable, if you use open/read rather than fopen/fread. Ian
