The questions will inevitably arise: How does Fossil perform? Does it use a lot of disk space or bandwidth? Is it scalable? In an attempt to answer these questions, this report looks at several projects that use fossil for configuration management and examines how well they are working. The following table is a summary of the results. (Last updated on 2018-06-04.) Explanation and analysis follows the table.
Project Number Of Artifacts Number Of Check-ins Project Duration
(as of 2018-06-04)		 Uncompressed Size Repository Size Compression Ratio Clone Bandwidth
[http://www.sqlite.org/src/timeline | SQLite] 77492 20686 6580 days
18.02 years 		5.6 GB 70.0 MB 80:1 51.1 MB
[http://core.tcl.tk/tcl/timeline | TCL] 161991 23146 7375 days
20.19 years 		8.0 GB 222.0 MB 36:1 150.5 MB
[/timeline | Fossil] 39148 11266 3971 days
10.87 years 		3.8 GB 42.0 MB 90:1 27.4 MB
[http://www.sqlite.org/slt/timeline | SLT] 2384 169 3474 days
9.51 years 		2.1 GB 145.9 MB 14:1 143.4 MB
[http://www.sqlite.org/th3.html | TH3] 12406 3718 3539 days
9.69 years 		544 MB 18.0 MB 30:1 14.7 MB
[http://www.sqlite.org/docsrc/timeline | SQLite Docs] 8752 2783 3857 days
10.56 years 		349.9 MB 16.3 MB 21:1 13.57 MB

Measured Attributes

In Fossil, every version of every file, every wiki page, every change to every ticket, and every check-in is a separate "artifact". One way to think of a Fossil project is as a bag of artifacts. Of course, there is a lot more than this going on in Fossil. Many of the artifacts have meaning and are related to other artifacts. But at a low level (for example when synchronizing two instances of the same project) the only thing that matters is the unordered collection of artifacts. In fact, one of the key characteristics of Fossil is that the entire project history can be reconstructed simply by scanning the artifacts in an arbitrary order. The number of check-ins is the number of times that the "commit" command has been run. A single check-in might change 3 or 4 files, or it might change dozens or hundreds of files. Regardless of the number of files changed, it still only counts as one check-in. The "Uncompressed Size" is the total size of all the artifacts within the repository assuming they were all uncompressed and stored separately on the disk. Fossil makes use of delta compression between related versions of the same file, and then uses zlib compression on the resulting deltas. The total resulting repository size is shown after the uncompressed size. On the right end of the table, we show the "Clone Bandwidth". This is the total number of bytes sent from server back to the client. The number of bytes sent from client to server is negligible in comparison. These byte counts include HTTP protocol overhead. In the table and throughout this article, "GB" means gigabytes (109 bytes) not gibibytes (230 bytes). Similarly, "MB" and "KB" means megabytes and kilobytes, not mebibytes and kibibytes.

Analysis And Supplemental Data

Perhaps the two most interesting data points in the above table are SQLite and SLT. SQLite is a long-running project with long revision chains. Some of the files in SQLite have been edited over a thousand times. Each of these edits is stored as a delta, and hence the SQLite project gets excellent 80:1 compression. SLT, on the other hand, consists of many large (megabyte-sized) SQL scripts that have one or maybe two edits each. There is very little delta compression occurring and so the overall repository compression ratio is much lower. Note also that quite a bit more bandwidth is required to clone SLT than SQLite. For the first nine years of its development, SQLite was versioned by CVS. The resulting CVS repository measured over 320MB in size. So, the developers were surprised to see that the equivalent Fossil project (the first nine years on SQLite) would clone with only 13MB of bandwidth. The "sync" protocol used by fossil has turned out to be surprisingly efficient. A typical check-in on SQLite might use 3 or 4KB of network bandwidth. For example, the [04eef9522386a59e] check-in used a single HTTP request of 2099 bytes and got back a reply of 1116 bytes. The sync protocol is efficient enough that, once cloned, Fossil can easily be used over a dial-up connection.