On 2006-05-30 14:49:52 -0400 Günther Noack <[EMAIL PROTECTED]> wrote:

> Am 30.05.2006 um 01:00 schrieb Quentin Mathé:
>> Yes, however I don't think it's a very wise choice to store  everything in 
>> files, because most file systems have bad performance  when you are dealing 
>> with huge number of files. I don't really know  what is the right choice 
>> for Grr. To take an example, for a mail  client (dealing with ten or 
>> hundred thousand mails quite often)  it's a better to store each mail 
>> folder or account in a file and  write a translator to present them as 
>> files in File Manager or to  other applications.

I think it depends on what you want to do with the mails, and how often you 
touch the file.  For example, removing a mail from the middle of the large file 
that stores all the mails would be slower than removing a file from a 
directory.  Personally, I prefer pushing things as much into the filesystem as 
possible, and selecting the correct filesystem.

But it seems that with translators, we can make that more or less configurable, 
and let the user select what is best for their system.

>> Bookmarks, contacts or feed articles could be serialized very  easily in 
>> one file and a simple translator may provide virtual  objects by mapping 
>> them to precise to XML nodes in the file format   (just supposing the 
>> serialization is done in XML here, plain text,  plist, binary could be 
>> better depending on the content).
> 
> In the current version of Grr, that's exactly what I do: On exit, Grr  
> serializes its list of Feeds into one single file. Every feed also  
> serializes its list of articles into the same file.
> 
> I don't want to keep this, because it turned out to be very slow on  startup 
> and exit when using it for some weeks, because the file can  become very big.

Maybe what you want is one file for the list of feeds, and one file for each 
feed?  Or maybe using a more database-like file format (like SQLite or Berkeley 
DB?).

...

> What's the advantage of storing everything in one big file? I know  that 
> NSArray is faster than a file system (because things are already  in memory), 
> but I wonder how many articles a user then needs to look  at to save time 
> compared to the 'multiple files' scenario.

AFAIK, the main advantage to storing everything in one big file is that a lot 
of filesystems don't handle having many small files very well.

And in all filesystems, reading many files from end to end is slower than 
reading a single large file from end to end, due to extra overhead in having to 
call open(2) for each file.  Although if the many files are each of reasonable 
length anyways, this overhead won't be that significant
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to