Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: [PATCH 6/6] Retain caches of submodule refs

From: Michael Haggerty <hidden>
Date: 2016-06-15 22:51:52

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@alum.mit.edu
http://softwareswirl.blogspot.com/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help