On 06.03.2014, at 18:03, Stephan Eggermont <[email protected]> wrote:
> Max wrote >> In my opinion there are other factors, like readability, maintenance etc, >> that are maybe more important than speed. > > I’m not totally convinced. The readability from the outside is limited by > having one file per method. > Mainstream tooling assumes one file per class. The emails from github to this > list are a good example > of the usability problems that leads to. I don’t want to suggest switching to > a larger granularity, as that > leads to another set of problems. I agree that we have to keep that in mind. And you are right that one file per method may be too granular. But at the moment (and I certainly have not done exhaustive work on this) I have no better solution. Since this is part of my Master’s thesis, the scope of what I have time for is limited and I will be very glad if I manage to finish FileSystem-Git. I’d rather not invent something, that then will turn out to be sub par and rather go with established protocols / methods, which may be inferior to a different solution, but of which I can at least estimate the possible drawbacks. This is not to say, that I don’t want to achieve the best that is possible, I’m just trying to avoid disappointment :) > > My point was more if we could mostly avoid the source view, and directly work > with the archive. > Why is working with single files fastest? Well, of course that is not generally the case, but when working with pack files, it can be. Pack files do have indexes and fanout tables, so searching for an object is easy. But usually, contrary to loose objects, objects in packs will be deltified to a certain degree (more deltas the more objects there are) and deltification incurs the cost of putting the object back together (a delta chain can be of any length in theory), which means multpile offset calculations and searches on the stream. In average (and this is just an educated guess) the access time will thus be greater than for loose objects. Max > > Stephan
