On 10/27/11 14:13, Philip Martin wrote:
Mark Phippard<markp...@gmail.com> writes:
I would imagine svn upgrade is almost entirely writes and I recall it does
quite a few transactions. So couldn't the linear slow down just be based on
the growth in the amount of bytes that are written to disk each time?
Yes, number of transactions matters a lot. However upgrade is a special
case that runs in a single SQLite transaction as this makes most
upgrades faster. Maybe for really large upgrades the huge transaction
is a problem? My 100,000 node working copy upgrades in 45 minutes.
I don't have too much files/directories either, currently: 1772120,
that's only an order of magnitude bigger.
What I could see is that svn's memory usage has grown constantly during
the operation. It started on about 20M resident and went to
approximately 60-80M.
I don't know for sure because I lost the interest in watching it in
about 3-4 days, so I'm just extrapolation from the last seen value
(sixty something megabytes on day 3). :)
Upgrade does a number of read queries as well as writes, but all within
the same transaction.
I guess, you are right, maybe the big transaction caused the major
slowdown.
