1<title>Fossil Performance</title> 2<h1 align="center">Performance Statistics</h1> 3 4The questions will inevitably arise: How does Fossil perform? 5Does it use a lot of disk space or bandwidth? Is it scalable? 6 7In an attempt to answers these questions, this report looks at several 8projects that use fossil for configuration management and examines how 9well they are working. The following table is a summary of the results. 10(Last updated on 2018-06-04.) 11Explanation and analysis follows the table. 12 13<table border=1> 14<tr> 15<th>Project</th> 16<th>Number Of Artifacts</th> 17<th>Number Of Check-ins</th> 18<th>Project Duration<br>(as of 2018-06-04)</th> 19<th>Uncompressed Size</th> 20<th>Repository Size</th> 21<th>Compression Ratio</th> 22<th>Clone Bandwidth</th> 23</tr> 24 25<tr align="center"> 26<td>[http://www.sqlite.org/src/timeline | SQLite] 27<td>77492 28<td>20686 29<td>6580 days<br>18.02 years 30<td>5.6 GB 31<td>70.0 MB 32<td>80:1 33<td>51.1 MB 34</tr> 35 36<tr align="center"> 37<td>[http://core.tcl.tk/tcl/timeline | TCL] 38<td>161991 39<td>23146 40<td>7375 days<br>20.19 years 41<td>8.0 GB 42<td>222.0 MB 43<td>36:1 44<td>150.5 MB 45</tr> 46 47<tr align="center"> 48<td>[/timeline | Fossil] 49<td>39148 50<td>11266 51<td>3971 days<br>10.87 years 52<td>3.8 GB 53<td>42.0 MB 54<td>90:1 55<td>27.4 MB 56</tr> 57 58<tr align="center"> 59<td>[http://www.sqlite.org/slt/timeline | SLT] 60<td>2384 61<td>169 62<td>3474 days<br>9.51 years 63<td>2.1 GB 64<td>145.9 MB 65<td>14:1 66<td>143.4 MB 67</tr> 68 69<tr align="center"> 70<td>[http://www.sqlite.org/th3.html | TH3] 71<td>12406 72<td>3718 73<td>3539 days<br>9.69 years 74<td>544 MB 75<td>18.0 MB 76<td>30:1 77<td>14.7 MB 78</tr> 79 80<tr align="center"> 81<td>[http://www.sqlite.org/docsrc/timeline | SQLite Docs] 82<td>8752 83<td>2783 84<td>3857 days<br>10.56 years 85<td>349.9 MB 86<td>16.3 MB 87<td>21:1 88<td>13.57 MB 89</tr> 90 91</table> 92 93<h2>Measured Attributes</h2> 94 95In Fossil, every version of every file, every wiki page, every change to 96every ticket, and every check-in is a separate "artifact". One way to 97think of a Fossil project is as a bag of artifacts. Of course, there is 98a lot more than this going on in Fossil. Many of the artifacts have meaning 99and are related to other artifacts. But at a low level (for example when 100synchronizing two instances of the same project) the only thing that matters 101is the unordered collection of artifacts. In fact, one of the key 102characteristics of Fossil is that the entire project history can be 103reconstructed simply by scanning the artifacts in an arbitrary order. 104 105The number of check-ins is the number of times that the "commit" command 106has been run. A single check-in might change a 3 or 4 files, or it might 107change dozens or hundreds of files. Regardless of the number of files 108changed, it still only counts as one check-in. 109 110The "Uncompressed Size" is the total size of all the artifacts within 111the repository assuming they were all uncompressed and stored 112separately on the disk. Fossil makes use of delta compression between related 113versions of the same file, and then uses zlib compression on the resulting 114deltas. The total resulting repository size is shown after the uncompressed 115size. 116 117On the right end of the table, we show the "Clone Bandwidth". This is the 118total number of bytes sent from server back to the client. The number of 119bytes sent from client to server is negligible in comparison. 120These byte counts include HTTP protocol overhead. 121 122In the table and throughout this article, 123"GB" means gigabytes (10<sup><small>9</small></sup> bytes) 124not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> 125(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" 126means megabytes and kilobytes, not mebibytes and kibibytes. 127 128<h2>Analysis And Supplemental Data</h2> 129 130Perhaps the two most interesting data points in the above table are SQLite 131and SLT. SQLite is a long-running project with long revision chains. 132Some of the files in SQLite have been edited over a thousand times. 133Each of these edits is stored as a delta, and hence the SQLite project 134gets excellent 80:1 compression. SLT, on the other hand, consists of 135many large (megabyte-sized) SQL scripts that have one or maybe two 136edits each. There is very little delta compression occurring and so the 137overall repository compression ratio is much lower. Note also that 138quite a bit more bandwidth is required to clone SLT than SQLite. 139 140For the first nine years of its development, SQLite was versioned by CVS. 141The resulting CVS repository measured over 320MB in size. So, the 142developers were surprised to see that the equivalent Fossil project (the 143first nine years on SQLite) would clone with only 13MB of bandwidth. 144The "sync" protocol 145used by fossil has turned out to be surprisingly efficient. A typical 146check-in on SQLite might use 3 or 4KB of network bandwidth. 147For example, the [04eef9522386a59e] check-in used a single HTTP request 148of 2099 bytes and got back a reply of 1116 bytes. 149The sync protocol is efficient enough that, once cloned, 150Fossil can easily be used over a dial-up connection. 151