Merge from vendor branch GCC:
[dragonfly.git] / contrib / cvs-1.12 / PROJECTS
CommitLineData
3142e03f
SS
1This is a list of projects for CVS. In general, unlike the things in
2the TODO file, these need more analysis to determine if and how
3worthwhile each task is.
4
5I haven't gone through TODO, but it's likely that it has entries that
6are actually more appropriate for this list.
7
80. Improved Efficency
9
10* CVS uses a single doubly linked list/hash table data structure for
11 all of its lists. Since the back links are only used for deleting
12 list nodes it might be beneficial to use singly linked lists or a
13 tree structure. Most likely, a single list implementation will not
14 be appropriate for all uses.
15
16 One easy change would be to remove the "type" field out of the list
17 and node structures. I have found it to be of very little use when
18 debugging, and each instance eats up a word of memory. This can add
19 up and be a problem on memory-starved machines.
20
21 Profiles have shown that on fast machines like the Alpha, fsortcmp()
22 is one of the hot spots.
23
24* Dynamically allocated character strings are created, copied, and
25 destroyed throughout CVS. The overhead of malloc()/strcpy()/free()
26 needs to be measured. If significant, it could be minimized by using a
27 reference counted string "class".
28
29* File modification time is stored as a character string. It might be
30 worthwile to use a time_t internally if the time to convert a time_t
31 (from struct stat) to a string is greater that the time to convert a
32 ctime style string (from the entries file) to a time_t. time_t is
33 an machine-dependant type (although it's pretty standard on UN*X
34 systems), so we would have to have different conversion routines.
35 Profiles show that both operations are called about the same number
36 of times.
37
38* stat() is one of the largest performance bottlenecks on systems
39 without the 4.4BSD filesystem. By spliting information out of
40 the filesystem (perhaps the "rename database") we should be
41 able to improve performance.
42
43* Parsing RCS files is very expensive. This might be unnecessary if
44 RCS files are only used as containers for revisions, and tag,
45 revision, and date information was available in easy to read
46 (and modify) indexes. This becomes very apparent with files
47 with several hundred revisions.
48
491. Improved testsuite/sanity check script
50
51* Need to use a code coverage tool to determine how much the sanity
52 script tests, and fill in the holes.
53