Should I memory-map this file?

This is a discussion on Should I memory-map this file? within the Linux Programming forums, part of the Platform Specific Boards category; I have a simple database file with a fixed number of records, each with a fixed length. I don't need ...

  1. #1
    Kung Fu Kitty Angus's Avatar
    Join Date
    Oct 2008
    Location
    Montreal, Canada
    Posts
    115

    Should I memory-map this file?

    I have a simple database file with a fixed number of records, each with a fixed length. I don't need to insert or delete anything, I just need to read records. Also, every record is merely dereferenced with an array-like index. All this to say that I don't need to bother with complicated indexing or any 3rd party libraries like SQLite.

    Furthermore, every instance of the app will read just 1 record then exit. Many instances could be running at the same time.

    I see the following options.

    1. Don't memory-map anything. Just seek to the target record and read it.
    2. Memory-map just the record I want.
    3. Memory-map the whole file.

    As I understand it, the biggest reason for memory-mapping files is to dispense with the overhead of system calls. If that's the case then there seems to be little point in going with 2 or 3, since they'll have the same number of system calls as 1 (1 seeks and reads, while 2 and 3 map and unmap). However, since multiple instances will be accessing this file, I'm wondering if there might be an advantage with memory-mapping there.

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,669
    >> However, since multiple instances will be accessing this file, I'm wondering if there might be an advantage with memory-mapping there.
    Probably. Map the whole thing as read-only and let the OS take care of the rest.

    gg

  3. #3
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    If you ONLY read this file and you don't write it (or even don't write it much), consider creating a tmpfs mount (old name RAMDISC) and throw that puppy into memory. At least then you aren't doing disc reads/writes all the time.

    Even if you are updating this file, you could still do this and then have a daemon that writes it back to disc every so often (like after a change is made).

    Andy

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Here's a kind of unothodox option: you can write a kernel module to create a memory device (really, thats what tmpfs, etc are). The device has a file handle, eg /dev/mymem, but resides in kernel memory (of which there is more than you might think) and gets serviced by it.

    See here:
    kernel memory char device

    A complication would be that this is not permanent storage, but anything involving memory will have to be copied to and from disk at some point, that's kind of a natural law, methinks.

    Not sure if I agree with your reasons for wanting to do this tho.
    Last edited by MK27; 08-06-2009 at 08:35 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. A development process
    By Noir in forum C Programming
    Replies: 37
    Last Post: 07-10-2011, 10:39 PM
  2. File Writing Problem
    By polskash in forum C Programming
    Replies: 3
    Last Post: 02-13-2009, 09:47 AM
  3. Post...
    By maxorator in forum C++ Programming
    Replies: 12
    Last Post: 10-11-2005, 08:39 AM
  4. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM
  5. archive format
    By Nor in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 08-05-2003, 07:01 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21