Re: [PATCH/RFC v2] read-cache: save index entry updates in ILOG index extension
On Fri, Aug 9, 2013 at 1:46 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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 tuples would not compress well, I suspect.
I was hoping that it still compresses well the discrete segments of
pathname. In the worst case we can group sha-1 together, separate from
pathnames.
>> 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.
We need to go through ILOG extension anyway for index sha-1
verification, so it's already read in kernel buffer. What we save is a
just malloc. But I'll try.
>
>> 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.
This patch is more about the idea, whether it makes sense. You would
(and did) find the patch somewhat disgusting later on.
>> @@ -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.
The reason I can't put index_state there is because this function is
called early, often before read_cache is is called. And I can't caller
it later because argv would be ruined by parse_options(). An option is
to convert argv to a string unconditionally in git.c, then
log_index_changes can be called much later, and with index_state
pointer.
>> +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?
Right. At the end of the commit message I mentioned about "git add
--undo". After I wrote it, I became more convinced it's the way to go.
That should be the UI, instead of letting the user hunt the right
entry through the index log. And then caller has the responsibility to
track changes and feed it to read-cache (CE_BASE trick is gone). And
it would record something like raw diff: a pair of old/new sha-1 and a
path name. This helps differentiate modified, deleted and added
entries that "git add --undo" may need to undo.
>> +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)
>> +
Re: [PATCH/RFC v2] read-cache: save index entry updates in ILOG index extension
Nguyễn Thái Ngọc Duy 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 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 tha
