git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Marco Costalba <mcostalba@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <junkio@cox.net>, Alex Riesen <raa.lkml@gmail.com>,
	Shawn Pearce <spearce@spearce.org>
Subject: Re: [RFC \ WISH] Add -o option to git-rev-list
Date: Sun, 10 Dec 2006 12:08:53 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0612101159530.12500@woody.osdl.org> (raw)
In-Reply-To: <e5bfff550612101151r5e77ddc0w8f61f36fc1f2920e@mail.gmail.com>



On Sun, 10 Dec 2006, Marco Costalba wrote:
> 
> - memory use: the next natural step with files is, instead of loading
> the file content in memory and *keep it there*, we could load one
> chunk at a time, index the chunk and discard. At the end we keep in
> memory only indexing info to quickly get to the data when needed, but
> the big part of data stay on the file.

Well, that's still just going slower than swapping.

The reason loading things into memory is nice is that:
 - in the common case, you don't need to do anything else.
 - if  the machine is low on memory, it can page things out just about as 
   easily as you could write things to a file anyway.

So don't worry too much about low-memory situations. Yes, there are cases 
where it's better to keep things in files and simply not have a big 
working set AT ALL, but if you keep something in a file and the file data 
is still part of the working set (ie you read it several times, but at the 
beginning and the end), that really isn't any better than having it in 
memory.

So the time to try to optimize memory usage is really only for "streaming 
behaviour" - where you need to touch something only once. Then the best 
option is to actually use a pipe and re-use the memory, but if you have 
file data, you can use things like fadvise(DONTNEED).

> - This is probably my ignorance, but experimenting with popen() I
> found I could not know *when* git-rev-list ends because both feof()
> and ferror() give 0 after a fread() with git-rev-list already defunct.

I suspect you had a bug somewhere. It could be a bug in stdio, but I doubt 
it.

You do realize that the correct way to check "feof()" is only _after_ 
fread() returns 0? 

Stdio ferror/feof is horrible to use corrrectly, and few people get it 
right.  Mostly because it's such a crap interface thanks to being "easy" 
to use and thus hiding all the error handling details on purpose.


  parent reply	other threads:[~2006-12-10 20:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-10 11:38 [RFC \ WISH] Add -o option to git-rev-list Marco Costalba
2006-12-10 14:54 ` Alex Riesen
2006-12-10 18:16 ` Linus Torvalds
2006-12-10 19:51   ` Marco Costalba
2006-12-10 20:00     ` globs in partial checkout? Michael S. Tsirkin
2006-12-10 20:13       ` Linus Torvalds
2006-12-10 21:07         ` Michael S. Tsirkin
2006-12-10 20:08     ` Linus Torvalds [this message]
2006-12-10 20:19       ` [RFC \ WISH] Add -o option to git-rev-list Linus Torvalds
2006-12-10 22:05         ` Marco Costalba
2006-12-10 22:09           ` Marco Costalba
2006-12-10 22:16           ` Linus Torvalds
2006-12-10 22:35             ` Marco Costalba
2006-12-10 22:53               ` Linus Torvalds
2006-12-11  0:15                 ` Marco Costalba
2006-12-11  0:51                   ` Linus Torvalds
2006-12-11  7:17                     ` Marco Costalba
2006-12-11 10:00                       ` Alex Riesen
2006-12-11 16:59                       ` Linus Torvalds
2006-12-11 17:07                         ` Linus Torvalds
2006-12-11 17:39                           ` Marco Costalba
2006-12-11 18:15                             ` Linus Torvalds
2006-12-11 18:59                               ` Marco Costalba
2006-12-11 19:25                                 ` Linus Torvalds
2006-12-11 20:28                                 ` Josef Weidendorfer
2006-12-11 20:40                                   ` Linus Torvalds
2006-12-11 20:54                                     ` Josef Weidendorfer
2006-12-11 21:14                                       ` Linus Torvalds
2006-12-15 18:45                                         ` Marco Costalba
2006-12-15 19:20                                           ` Linus Torvalds
2006-12-15 20:41                                             ` Marco Costalba
2006-12-15 21:04                                               ` Marco Costalba
2006-12-11  9:26                   ` Josef Weidendorfer
2006-12-11 12:52                     ` Marco Costalba
2006-12-11 13:28                       ` Josef Weidendorfer
2006-12-11 17:28                         ` Marco Costalba
2006-12-11 11:39     ` Andreas Ericsson
2006-12-11 12:59       ` Marco Costalba
2006-12-11 13:40         ` Andreas Ericsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0612101159530.12500@woody.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=mcostalba@gmail.com \
    --cc=raa.lkml@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).