On Fri, 29 Aug 2008, Shawn O. Pearce wrote: > Oh, yea, that makes sense. It still seems like playing with fire. > > I'd rather the caller pass in the proper offset than rely on it > being the current position of the fd. Especially if the caller > does actually have it available. > > If you change anything, I'd like to see this lseek(SEEK_CUR) go away. Done. I struggled a bit since it simply didn't work initially -- see the first patch in the updated series. > > And another thing I had in store (but for which you _again_ beat me to :-) ) > > is to realign data reads onto filesystem blocks. > > That _really_ made the JGit code ugly. But I think its worth it. See my version. I think it is reasonably clear. > I also want to try and buffer the whole object appending we do > during fixThinPack(), as right now we write the object header in > one write and then compressed data bursts in the others. Moving it > to at least write a full 4k at a time should remove about 2 write > calls per object. Yep. In the C git case, moving to sha1write() added that buffering for free. Nicolas -- 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
