Nicolas Pitre <nico@xxxxxxx> writes: > On Wed, 15 Aug 2007, Jon Smirl wrote: > >> On 8/15/07, Martin Koegler <mkoegler@xxxxxxxxxxxxxxxxx> wrote: >> > git-pack-objects knows the order, in which it will use the objects. A >> > seperate thread could pre-read the next object and wait until the main >> > thread starts processing it. After the read is complete, another >> > thread could start computing the delta index. >> >> The hope is that the new adaptive read ahead code in the kernel will >> get this right and you won't need the second thread. Letting the >> kernel handle the read ahead will dynamically scale as other demands >> are made on the host. There's effectively only one read ahead cache in >> the system, only the kernel really knows how to divide it up between >> competing apps. > > No read ahead will ever help the delta search phase. Well, the delta search phase consists of computing a delta index and then matching against it. If I understand correctly, delta indices for the search window are kept, and the current file is compared against them. Locality might be better if just one delta index gets calculated and then compared with all _upcoming_ delta candidates in one go. No idea whether it would pay off the complications. -- David Kastrup - 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
