On Sat, Jul 1, 2017 at 10:33 PM, Junio C Hamano <gits...@pobox.com> wrote: > Christian Couder <christian.cou...@gmail.com> writes: > >>> I think it would be good to ensure the >>> interface is robust and performant enough to actually replace the current >>> object store interface (even if we don't actually do that just yet). >> >> I agree that it should be robust and performant, but I don't think it >> needs to be as performant in all cases as the current object store >> right now. > > That sounds like starting from a defeatest position. Is there a > reason why you think using an external interface could never perform > well enough to be usable in everyday work?
Perhaps in the future we will be able to make it as performant as, or perhaps even more performant, than the current object store, but in the current implementation the following issues mean that it will be less performant: - The external object stores are searched for an object after the object has not been found in the current object store. This means that searching for an object will be slower if the object is in an external object store. To overcome this the "have" information (when the external helper implements it) could be merged with information about what objects are in the current object store, for example in a big table or bitmap, so that only one lookup in this table or bitmap would be needed to know if an object is available and in which object store it is. But I really don't want to get into this right now. - When an external odb helper retrieves an object and passes it to Git, Git (or the helper itself in "fault in" mode) then stores the object in the current object store. This is because we assume that it will be faster to retrieve it again if it is cached in the current object store. There could be a capability that asks Git to not cache the objects that are retrieved from the external odb, but again I don't think it is necessary at all to implement this right now. I still think though that in some cases, like when the external odb is used to implement a bundle clone, using the external odb mechanism can already be more performant.
