git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC v2] read-cache: save index entry updates in ILOG index extension
Date: Thu, 08 Aug 2013 11:46:18 -0700	[thread overview]
Message-ID: <7veha49g1x.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1375966270-10968-1-git-send-email-pclouds@gmail.com> ("Nguyễn	Thái Ngọc Duy"'s message of "Thu, 8 Aug 2013 19:51:10 +0700")

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> Old operation's updates are removed as new ones are added to keep the
> size under 1 MB. ILOG keeps minimum 10 operations regardless of its
> size. These contansts should be configurable later one. ILOG content
> will be compressed later on so that it leaves minimum
> footprint.

List of <sha-1, pathname> tuples would not compress well, I suspect.

> Because it's only needed at index writing time, read-only
> operations won't pay the cost for decompressing and compressing ILOG.

Another idea is to lazily read existing ILOG by (1) keeping just an
offset in the originating index file at read_index() time and (2)
reading it on demand when ":-4:Makefile" was asked for.

> diff --git a/cache.h b/cache.h
> index 85b544f..a2156bf 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -168,6 +168,7 @@ struct cache_entry {
>  
>  /* used to temporarily mark paths matched by pathspecs */
>  #define CE_MATCHED           (1 << 26)
> +#define CE_BASE              (1 << 27)

As this is not about pathspec match, please have its own comment
line (or a blank line, if this goes without comment) above this new
line.

> @@ -277,6 +278,7 @@ struct index_state {
>  		 initialized : 1;
>  	struct hash_table name_hash;
>  	struct hash_table dir_hash;
> +	struct strbuf *index_log;
>  };

Sane to have this as a per-index_state variable.

> +extern void log_index_changes(const char *prefix, const char **argv);

Not sane to name this function _index_anything and not to have index_state
as its first parameter, breaking the naming convention.

> diff --git a/read-cache.c b/read-cache.c
> index c3d5e35..4021667 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -14,6 +14,7 @@
>  #include "resolve-undo.h"
>  #include "strbuf.h"
>  #include "varint.h"
> +#include "quote.h"
>  
>  static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really);
>  
> @@ -33,8 +34,10 @@ static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int reall
>  #define CACHE_EXT(s) ( (s[0]<<24)|(s[1]<<16)|(s[2]<<8)|(s[3]) )
>  #define CACHE_EXT_TREE 0x54524545	/* "TREE" */
>  #define CACHE_EXT_RESOLVE_UNDO 0x52455543 /* "REUC" */
> +#define CACHE_EXT_INDEX_LOG 0x494C4F47 /* "ILOG" */
>  
>  struct index_state the_index;
> +static struct strbuf log_message = STRBUF_INIT;

Not sane to have a single global here.  Give the callers a helper
function to prepare a ilog message into a strbuf they prepare before
they muck with argc/argv with parse_options(), and have them pass
that strbuf to

	log_index_changes(struct index_state *, struct strbuf *);

and supply the usual

	#define log_cache_changes(logmsg) log_index_changes(&the_index, (logmsg))

macro, inside "#ifndef NO_THE_INDEX_COMPATIBILITY_MACROS" section.

> @@ -1509,6 +1520,14 @@ int read_index_from(struct index_state *istate, const char *path)
>  		src_offset += extsize;
>  	}
>  	munmap(mmap, mmap_size);
> +	if (istate == &the_index) {

Yuck.  Why can't the callers operate on their own copies of the
in-core index and get the same benefit?

> +		for (i = 0; i < istate->cache_nr; i++) {
> +			struct cache_entry *ce = istate->cache[i];
> +			if (ce_stage(ce))
> +				continue;
> +			ce->ce_flags |= CE_BASE;
> +		}
> +	}
>  	return istate->cache_nr;

> +static void get_updated_entries(struct index_state *istate,
> +				struct cache_entry ***cache_out,
> +				unsigned int *cache_nr_out)
> +{
> +	struct cache_entry **cache;
> +	unsigned int i, nr, cache_nr = 0;
> +
> +	*cache_nr_out = 0;
> +	*cache_out = NULL;
> +	for (i = 0; i < istate->cache_nr; i++) {
> +		if (istate->cache[i]->ce_flags & CE_BASE)
> +			continue;
> +		cache_nr++;
> +	}
> +	if (!cache_nr)
> +		return;
> +	cache = xmalloc(cache_nr * sizeof(*istate->cache));
> +	for (i = nr = 0; i < istate->cache_nr; i++) {
> +		struct cache_entry *ce = istate->cache[i];
> +		if (ce->ce_flags & CE_BASE)
> +			continue;
> +		cache[nr++] = ce;
> +	}
> +	*cache_out = cache;
> +	*cache_nr_out = cache_nr;
> +}

I can read what the function does, but I do not understand the
assumption this code makes.

Is this assuming that any newly created cache_entry that goes to
the_index via add_index_entry() will not have CE_BASE bit set?  Some
codepaths try to preserve the flags bit they do not care and/or
understand (e.g. rename_index_entry_at() creates a new ce with a new
name, and keeps most of the flags bit except for the name-hash state
bits), so CE_BASE will be propagated from the original to the new
one, I think.

You seem to be recording the state _after_ the change---that can be
read without the extension, can't it?  I thought we care more about
the state that was _lost_ by the change.

Recording the state after the change misses deleted entries, doesn't
it?

> +static void write_index_log(struct strbuf *sb,
> +			    const struct strbuf *old_log,
> +			    const struct strbuf *msg,
> +			    struct cache_entry **cache,
> +			    unsigned int cache_nr)
> +{
> +	struct strbuf body = STRBUF_INIT;
> +	unsigned int i, size, nr, body_len, hdr_len;
> +	const char *end, *p;
> +	strbuf_addf(&body, "%s%c", msg->buf, '\0');
> +	for (i = 0; i < cache_nr; i++)
> +		strbuf_addf(&body, "%s %s%c", sha1_to_hex(cache[i]->sha1),
> +			    cache[i]->name, '\0');

We do not care about file modes (e.g. "update-index --chmod")?

> +	strbuf_addf(sb, "%u %u%c", (unsigned int)cache_nr, (unsigned int)body.len, '\0');

OK, so the header records how many entries there are and how big the
record is, followed by a list of tuples that describe what got
changed.

> +	strbuf_addbuf(sb, &body);
> +	strbuf_release(&body);
> +
> +	if (!old_log)
> +		return;
> +
> +	size = sb->len;
> +	nr = cache_nr;
> +	end = old_log->buf + old_log->len;
> +	p = old_log->buf;
> +	while (p < end && (size < 1024 * 1024 || nr < 10)) {
> +		if (sscanf(p, "%u %u", &cache_nr, &body_len) != 2) {
> +			error("fail to parse old index log at %u", (unsigned int)(p - old_log->buf));
> +			break;
> +		}

And that header is used to determine how much to bulk copy from the
stack of old records.

>  int write_index(struct index_state *istate, int newfd)
>  {
>  	git_SHA_CTX c;
> @@ -1780,6 +1879,11 @@ int write_index(struct index_state *istate, int newfd)
>  	int entries = istate->cache_nr;
>  	struct stat st;
>  	struct strbuf previous_name_buf = STRBUF_INIT, *previous_name;
> +	unsigned int index_log_nr = 0;
> +	struct cache_entry **index_log_entries = NULL;
> +
> +	if (istate == &the_index && log_message.len)
> +		get_updated_entries(istate, &index_log_entries, &index_log_nr);

Yuck about "istate == &the_index" again.

>  	for (i = removed = extended = 0; i < entries; i++) {
>  		if (cache[i]->ce_flags & CE_REMOVE)
> @@ -1846,6 +1950,23 @@ int write_index(struct index_state *istate, int newfd)
>  		if (err)
>  			return -1;
>  	}
> +	if (index_log_entries && log_message.len) {
> +		struct strbuf sb = STRBUF_INIT;
> +		write_index_log(&sb, istate->index_log, &log_message,
> +				index_log_entries, index_log_nr);
> +		err = write_index_ext_header(&c, newfd, CACHE_EXT_INDEX_LOG,
> +					     sb.len) < 0
> +			|| ce_write(&c, newfd, sb.buf,
> +				    sb.len) < 0;
> +		if (istate->index_log)
> +			strbuf_release(istate->index_log);
> +		else
> +			istate->index_log = xmalloc(sizeof(*istate->index_log));
> +		*istate->index_log = sb;
> +		if (err)
> +			return -1;
> +	}
> +	free(index_log_entries);
>  
>  	if (ce_flush(&c, newfd) || fstat(newfd, &st))
>  		return -1;

  reply	other threads:[~2013-08-08 18:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-04  6:28 [PATCH/RFC] add: support saving the last <n> versions of the index Nguyễn Thái Ngọc Duy
2013-08-08 12:51 ` [PATCH/RFC v2] read-cache: save index entry updates in ILOG index extension Nguyễn Thái Ngọc Duy
2013-08-08 18:46   ` Junio C Hamano [this message]
2013-08-09 13:32     ` Duy Nguyen

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=7veha49g1x.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /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).