On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
> dir.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
> dir.h | 60 +++++++++++++++++++++++++++
> 2 files changed, 189 insertions(+), 21 deletions(-)
[]
> +struct untracked_cache_dir {
> + struct untracked_cache_dir **dirs;
> + char **untracked;
> + /* null SHA-1 means this directory does not have .gitignore */
> + unsigned char exclude_sha1[20];
> + struct stat_data stat_data;
> + unsigned int check_only : 1;
> + unsigned int untracked_nr : 29;
> + unsigned int untracked_alloc, dirs_nr, dirs_alloc;
> + char name[1];
> +};
Are we utilizing the CPU and the L2 cache in a good way ?
I would consider to re-arrange, according to the following rule:
- 64 bit ints first (we do not have any)
- pointers (may be 64 or 32 bits)
- structs
- ints
- chars
And then we have the question why untracked_nr gets 29 bits,
and check_only one bit, which means we have 2 bits spare ?
>From what I know from CPUs and compilers it could be slighty better to give
32 bits to untracked_nr and either 1 bit to check_only,
or simply make check_only a char.
Or do I miss something ?
> + struct untracked_cache_dir **dirs;
> + char **untracked;
> + /* null SHA-1 means this directory does not have .gitignore */
> + struct stat_data stat_data;
> + unsigned char exclude_sha1[20];
> + unsigned int check_only : 1;
> + unsigned int untracked_nr : 29;
> + unsigned int untracked_alloc, dirs_nr, dirs_alloc;
> + char name[1];
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html