Zbynek Winkler <address@hidden> writes:
[...]
~2 hours for downloading monotone complete source with WinXP
1.8GHz, 512MB RAM (eats 100% CPU time). Means, not downloding. The
verification need the time. But is only at first connect. Later
it works faster.
Well... I can see it needs time -- but ~2 hours?? [...]
It seems pretty silly to me too. How much profiling has been done to
reduce this time? During a brief strace (taken during various phases
of the 45 minutes of the initial pull on my fast workstation), there
seemed to be ample low-level opportunities for speedup.
Socket I/O and status updating during the pull seemed rather wasteful
for example: a bunch of select-for-1us-delay / select-again / time /
read / write-status system calls in a close loop. It looks like a
busy wait with lots of unnecessary screen I/O.
Later on during what must have been verification, the db file is
processed with tons more system calls (llseek, read, write, ...), even
though mmap is available and concurrency is not exactly an issue.
But these sorts of micro things must be capable of incremental
improvement. My big worry is whether algorithmically an excess of
work is imposed on clients. For example, how necessary is it that
each historical crypto operation be redone/rechecked? Is it really
essential that each client database be a complete copy of the master,
as opposed to being fetched on demand?
Now I may have a few details wrong in the above, not having examined
monotone internals deeply or lately. But if the usage scenario of a
new user wanting to fetch a release from a monotone-hosted project is
so overweight compared to other alternatives, that's just not great.