[Monotone-devel] Scalability question

[Jonathan S. Shapiro]

If I understand the documents correctly, there are a whole lot of places
in the monotone schema that are very similar to things we did in OpenCM.
One of these bit us badly on scalability. I want to identify the issue,
explain how it bit us, and ask whether it has been a problem in
monotone. If not, why not?

The Monotone "Manifest" is directly equivalent to the OpenCM "Change"
object. We went through various iterations on our Change objects, and we
hit two scalability issues. The first arises with very large projects.
The second impacts initial checkout (in monotone, it would probably
arise in push/pull rather than checkout).

Like monotone, OpenCM does not store entries for directories; they are
implicit in the file paths. In contrast to Monotone, OpenCM adds a level
of indirection between our Change records and our Content objects. The
intermediate object is called an Entity. It stores the (file-name,
content-sha1) pair and a couple of other things that aren't important
for this question.

Consider a mid-sized project such as EROS, which has ~20,000 source
files. [For calibration, OpenBSD is *much* larger]. This means 20,000
sha-1's in the Manifest/Change. In OpenCM, these are stored in binary
form, so each sha-1 occupies 20 bytes, and the resulting Change object
is about 400 kilobytes.

This particular object sees a lot of delta computations, and simply
reading and writing it takes a noticeable amount of time. Also, the need
to sync a 400 kbyte object in order to begin a checkout is very
disconcerting to users -- especially when you are doing it over a slow
link at (e.g.) a hotel or (e.g.) a PPP link [Yes, a lot of people really
still use dial-up).

I am interested to know if this has been a scalability issue in
monotone? What performance result might I expect if I load EROS into
monotone?

If it *has* been a scalability issue, I have some hindsight suggestions
to offer based on the OpenCM experiences, but I don't want to seem
pushy.