On 08/17/2011 12:45 AM, Junio C Hamano wrote:
> All the changes except for this one made sense to me, but I am not sure
> about this one. How often do we look into different submodule refs in the
> same process over and over again?
As I've mentioned, I am not very familiar with submodules and I don't
know what actions in submodules can be triggered from the top-level
project. Here is the only code path that I can find in the current git
code that causes submodule refs to be read at all:
setup_revisions() with opt->submodule is set,
which can only happen when called via merge_submodule(),
which is called from merge_file() in merge-recursive.c,
which is called by process_renames() and merge_content(),
which are both ultimately called from merge_trees().
I don't know how often this can happen during the lifetime of one process.
The cost of retaining the submodule ref caches is roughly 100 bytes per
reference of memory. Another side effect is that the submodule caches
never have to be cleaned up; this saves a list walk and one free() per
cached reference if the refs for more than one submodule are accessed.
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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