Re: [Q] large flat files usage
Re: [Q] large flat files usage
- Subject: Re: [Q] large flat files usage
- From: Mike Laster <email@hidden>
- Date: Thu, 27 Jun 2002 21:26:50 -0400
On 6/20/02 8:46 PM, "Phillip Morelock" <email@hidden>
wrote:
>
On 6/20/02 5:33 PM, "Mike Laster" <email@hidden> wrote:
>
> You can hide it behind an API like:
>
>
>
> - (void) readBuffer:(void *)inBuffer length:(unsigned long) inLength
>
> fromLocation:(off_t) inLocation;
>
> - (void) writeBuffer:(void *)inBuffer length:(unsigned long) inLength
>
> toLocation:(off_t) inLocation;
>
>
>
> And implement everything in terms of this API.
>
>
Thanks for the voice of experience.
>
>
That's kind of where my (admittedly unrefined) instincts were pulling me,
>
into an offset-indexing scheme. Actually seems like kind of a fun
>
algorithm...enjoyed your description.
>
>
The only thing now that I am having trouble wrapping my head around is
>
writing in the middle of the file. Say, you insert two rows at (say) lines
>
3 and 4 in a 20000000 line file...., "pushing" the rest of the file down.
>
>
Is this in fact what physically happens? Does the (OS/filesystem) have to
>
shove everything over to make room, like when you "insert" an element in the
>
middle of a memory array (where you actually have to copy each of the
>
remaining elements)? If so, an expensive and seemingly unpractical
>
operation when it comes to inserting a 50-byte record in a 20Mbyte file. Or
>
is there something I'm missing conceptually? Sure feels like it!
I avoided that issue because I could constrain all of my data elements to be
fixed size. I have a fixed-size hash table at the front of the file, and I
only append new fixed-size records. I don't bother with delete at all,
since I don't really have to for my needs.
So, A fresh file contains a header with various control info, and an empty
hash table. When I insert the first record, it goes to offset 0, which is
immediately following the hash table. I then update the header to say that
the next available offset is 1. That way, writes are append-only, except
for updating the header and hash table, which never grow.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.