Resource Consumption

This page is about CVS's use of system resources like memory, CPU, etc. It focuses on hacking CVS in order to improve the situation. If you want a more "user-level" discussion of what to expect, see the System Requirements Information Page.

CVS server: Compression (CPU Usage)

Using -z 3 instead of -z 9 will use about one-third the CPU and provide almost the same quality of compression (within 10 percent). Patching the CVS server to only allow -z 3 is recommended.

Large Files

Storing large files in CVS will potentially use a lot of memory. First, if you are using a version of CVS older than about CVS 1.10, few of these comments will apply (CVS 1.10 is probably, for the most part, better than previous versions, but it is certainly _different_).

Large Files - rcs.c (Server and Local)

CVS (function RCS_deltas with RCS_FETCH) stores the entire files in contiguous memory. This can lead to fragmentation when multiple files are processed. For example, suppose that CVS allocates 30 megabytes, 50 megabytes, and then 70 megabytes. Now CVS is using 150 megabytes when it could be using 70 without much trouble. The fix, of course, is to have RCS_deltas pass the data through a callback (similar to the pfn and callerdat arguments to RCS_checkout).

For checking out the head revision, there is no reason for CVS to store the entire file in memory at all. This is the case in which RCS_checkout gets the contents itself rather than calling RCS_deltas. A few random thoughts on the low-level interfaces needed: (1) need read() or getline() analogues to call instead of rcsbuf_getkey, (2) Such interfaces also can be used by RCS_deltas so that it doesn't need to read the whole "text" field into contiguous memory to pass to linevector_add, (3) Probably this gets cleaner if RCS_checkout is split into a function which only passes data through callbacks (pfn and callerdat, plus new interfaces for modes and such), and a function which deals with files (modes, PreservePermissions, &c), and calls the first function to get the data.

For checking out non-head revisions, probably want to replace/supplement the RCS file format with something which obviates the need for keeping entire files in memory. For example, some systems just provide the ability to keep binary revisions in compressed files, one file per revision. Simple but effective.

Large Files - Command Line Client

Send_modified in client.c reads the whole file into contiguous memory. It would be simple to rewrite it to just read the data from the file as it sends it. Likewise update_entries.