This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fread() using mmaped buffer for IO


Nobin Mathew <nobin.mathew@gmail.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]