Fossil SCM
Update the performance stats webpage.
Commit
04eef9522386a59e31063b9300a5b9670c2be146
Parent
35c25558cbffcb7…
1 file changed
+48
-59
+48
-59
| --- www/stats.wiki | ||
| +++ www/stats.wiki | ||
| @@ -5,96 +5,89 @@ | ||
| 5 | 5 | Does it use a lot of disk space or bandwidth? Is it scalable? |
| 6 | 6 | |
| 7 | 7 | In an attempt to answers these questions, this report looks at several |
| 8 | 8 | projects that use fossil for configuration management and examines how |
| 9 | 9 | well they are working. The following table is a summary of the results. |
| 10 | -(Last updated on 2012-02-26.) | |
| 10 | +(Last updated on 2015-02-28.) | |
| 11 | 11 | Explanation and analysis follows the table. |
| 12 | 12 | |
| 13 | 13 | <table border=1> |
| 14 | 14 | <tr> |
| 15 | 15 | <th>Project</th> |
| 16 | 16 | <th>Number Of Artifacts</th> |
| 17 | 17 | <th>Number Of Check-ins</th> |
| 18 | -<th>Project Duration<br>(as of 2009-08-23)</th> | |
| 19 | -<th>Average Check-ins Per Day</th> | |
| 18 | +<th>Project Duration<br>(as of 2015-02-28)</th> | |
| 20 | 19 | <th>Uncompressed Size</th> |
| 21 | 20 | <th>Repository Size</th> |
| 22 | 21 | <th>Compression Ratio</th> |
| 23 | 22 | <th>Clone Bandwidth</th> |
| 24 | 23 | </tr> |
| 25 | 24 | |
| 26 | 25 | <tr align="center"> |
| 27 | 26 | <td>[http://www.sqlite.org/src/timeline | SQLite] |
| 28 | -<td>41113 | |
| 29 | -<td>9943 | |
| 30 | -<td>4290 days<br>11.75 yrs | |
| 31 | -<td>2.32 | |
| 32 | -<td>2.09 GB | |
| 33 | -<td>33.2 MB | |
| 34 | -<td>63:1 | |
| 35 | -<td>23.2 MB | |
| 27 | +<td>56089 | |
| 28 | +<td>14357 | |
| 29 | +<td>5388 days<br>14.75 yrs | |
| 30 | +<td>3.4 GB | |
| 31 | +<td>45.5 MB | |
| 32 | +<td>73:1 | |
| 33 | +<td>29.9 MB | |
| 36 | 34 | </tr> |
| 37 | 35 | |
| 38 | 36 | <tr align="center"> |
| 39 | 37 | <td>[http://core.tcl.tk/tcl/timeline | TCL] |
| 40 | -<td>74806 | |
| 41 | -<td>13541 | |
| 42 | -<td>5085 days<br>13.92 yrs | |
| 43 | -<td>2.66 | |
| 44 | -<td>5.2 GB | |
| 45 | -<td>86 MB | |
| 46 | -<td>60:1 | |
| 47 | -<td>67.0 MB | |
| 38 | +<td>139662 | |
| 39 | +<td>18125 | |
| 40 | +<td>6183 days<br>16.93 yrs | |
| 41 | +<td>6.6 GB | |
| 42 | +<td>192.6 MB | |
| 43 | +<td>34:1 | |
| 44 | +<td>117.1 MB | |
| 48 | 45 | </tr> |
| 49 | 46 | |
| 50 | 47 | <tr align="center"> |
| 51 | 48 | <td>[/timeline | Fossil] |
| 52 | -<td>15561 | |
| 53 | -<td>3764 | |
| 54 | -<td>1681 days<br>4.6 yrs | |
| 55 | -<td>2.24 | |
| 56 | -<td>721 MB | |
| 57 | -<td>18.8 MB | |
| 58 | -<td>38:1 | |
| 59 | -<td>12.0 MB | |
| 49 | +<td>29937 | |
| 50 | +<td>8238 | |
| 51 | +<td>2779 days<br>7.61 yrs | |
| 52 | +<td>2.3 GB | |
| 53 | +<td>34.0 MB | |
| 54 | +<td>67:1 | |
| 55 | +<td>21.5 MB | |
| 60 | 56 | </tr> |
| 61 | 57 | |
| 62 | 58 | <tr align="center"> |
| 63 | 59 | <td>[http://www.sqlite.org/slt/timeline | SLT] |
| 64 | -<td>2174 | |
| 65 | -<td>100 | |
| 66 | -<td>1183 days<br>3.24 yrs | |
| 67 | -<td>0.08 | |
| 68 | -<td>1.94 GB | |
| 69 | -<td>143 MB | |
| 70 | -<td>12:1 | |
| 71 | -<td>141 MB | |
| 60 | +<td>2278 | |
| 61 | +<td>136 | |
| 62 | +<td>2282 days<br>6.25 yrs | |
| 63 | +<td>2.0 GB | |
| 64 | +<td>144.7 MB | |
| 65 | +<td>13:1 | |
| 66 | +<td>142.1 MB | |
| 72 | 67 | </tr> |
| 73 | 68 | |
| 74 | 69 | <tr align="center"> |
| 75 | 70 | <td>[http://www.sqlite.org/th3.html | TH3] |
| 76 | -<td>5624 | |
| 77 | -<td>1472 | |
| 78 | -<td>1248 days<br>3.42 yrs | |
| 79 | -<td>1.78 | |
| 80 | -<td>252 MB | |
| 81 | -<td>12.5 MB | |
| 82 | -<td>20:1 | |
| 83 | -<td>12.2 MB | |
| 71 | +<td>8729 | |
| 72 | +<td>2406 | |
| 73 | +<td>2347 days<br>6.43 yrs | |
| 74 | +<td>386 MB | |
| 75 | +<td>15.2 MB | |
| 76 | +<td>25:1 | |
| 77 | +<td>12.6 MB | |
| 84 | 78 | </tr> |
| 85 | 79 | |
| 86 | 80 | <tr align="center"> |
| 87 | 81 | <td>[http://www.sqlite.org/docsrc/timeline | SQLite Docs] |
| 88 | -<td>3664 | |
| 89 | -<td>1003 | |
| 90 | -<td>1567 days<br>4.29 yrs | |
| 91 | -<td>0.64 | |
| 92 | -<td>108 MB | |
| 93 | -<td>6.6 MB | |
| 94 | -<td>16:1 | |
| 95 | -<td>5.71 MB | |
| 82 | +<td>5503 | |
| 83 | +<td>1631 | |
| 84 | +<td>2666 days<br>7.30 yrs | |
| 85 | +<td>194 MB | |
| 86 | +<td>10.9 MB | |
| 87 | +<td>17:1 | |
| 88 | +<td>8.37 MB | |
| 96 | 89 | </tr> |
| 97 | 90 | |
| 98 | 91 | </table> |
| 99 | 92 | |
| 100 | 93 | <h2>Measured Attributes</h2> |
| @@ -117,13 +110,11 @@ | ||
| 117 | 110 | The "Uncompressed Size" is the total size of all the artifacts within |
| 118 | 111 | the repository assuming they were all uncompressed and stored |
| 119 | 112 | separately on the disk. Fossil makes use of delta compression between related |
| 120 | 113 | versions of the same file, and then uses zlib compression on the resulting |
| 121 | 114 | deltas. The total resulting repository size is shown after the uncompressed |
| 122 | -size. For this chart, "fossil rebuild --compress" was run on each repository | |
| 123 | -prior to measuring its compressed size. Repository sizes would typically | |
| 124 | -be 20% larger without that rebuild. | |
| 115 | +size. | |
| 125 | 116 | |
| 126 | 117 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | 118 | total number of bytes sent from server back to the client. The number of |
| 128 | 119 | bytes sent from client to server is negligible in comparison. |
| 129 | 120 | These byte counts include HTTP protocol overhead. |
| @@ -138,22 +129,20 @@ | ||
| 138 | 129 | |
| 139 | 130 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | 131 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | 132 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | 133 | Each of these edits is stored as a delta, and hence the SQLite project |
| 143 | -gets excellent 63:1 compression. SLT, on the other hand, consists of | |
| 134 | +gets excellent 73:1 compression. SLT, on the other hand, consists of | |
| 144 | 135 | many large (megabyte-sized) SQL scripts that have one or maybe two |
| 145 | 136 | edits each. There is very little delta compression occurring and so the |
| 146 | 137 | overall repository compression ratio is much lower. Note also that |
| 147 | 138 | quite a bit more bandwidth is required to clone SLT than SQLite. |
| 148 | 139 | |
| 149 | 140 | For the first nine years of its development, SQLite was versioned by CVS. |
| 150 | 141 | The resulting CVS repository measured over 320MB in size. So, the |
| 151 | -developers were surprised to see that this entire project could be cloned in | |
| 152 | -fossil using only about 23.2MB of network traffic. (This 23.2MB includes | |
| 153 | -all the changes to SQLite that have been made since the conversion from | |
| 154 | -CVS. Of those changes are omitted, the clone bandwidth drops to 13MB.) | |
| 142 | +developers were surprised to see that the equivalent Fossil project (the | |
| 143 | +first nine years on SQLite) would clone with only 13MB of bandwidth. | |
| 155 | 144 | The "sync" protocol |
| 156 | 145 | used by fossil has turned out to be surprisingly efficient. A typical |
| 157 | 146 | check-in on SQLite might use 3 or 4KB of network bandwidth total, hardly |
| 158 | 147 | worth measuring. The sync protocol is efficient enough that, once cloned, |
| 159 | 148 | Fossil could easily be used over a dial-up connection. |
| 160 | 149 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -5,96 +5,89 @@ | |
| 5 | Does it use a lot of disk space or bandwidth? Is it scalable? |
| 6 | |
| 7 | In an attempt to answers these questions, this report looks at several |
| 8 | projects that use fossil for configuration management and examines how |
| 9 | well they are working. The following table is a summary of the results. |
| 10 | (Last updated on 2012-02-26.) |
| 11 | Explanation 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 2009-08-23)</th> |
| 19 | <th>Average Check-ins Per Day</th> |
| 20 | <th>Uncompressed Size</th> |
| 21 | <th>Repository Size</th> |
| 22 | <th>Compression Ratio</th> |
| 23 | <th>Clone Bandwidth</th> |
| 24 | </tr> |
| 25 | |
| 26 | <tr align="center"> |
| 27 | <td>[http://www.sqlite.org/src/timeline | SQLite] |
| 28 | <td>41113 |
| 29 | <td>9943 |
| 30 | <td>4290 days<br>11.75 yrs |
| 31 | <td>2.32 |
| 32 | <td>2.09 GB |
| 33 | <td>33.2 MB |
| 34 | <td>63:1 |
| 35 | <td>23.2 MB |
| 36 | </tr> |
| 37 | |
| 38 | <tr align="center"> |
| 39 | <td>[http://core.tcl.tk/tcl/timeline | TCL] |
| 40 | <td>74806 |
| 41 | <td>13541 |
| 42 | <td>5085 days<br>13.92 yrs |
| 43 | <td>2.66 |
| 44 | <td>5.2 GB |
| 45 | <td>86 MB |
| 46 | <td>60:1 |
| 47 | <td>67.0 MB |
| 48 | </tr> |
| 49 | |
| 50 | <tr align="center"> |
| 51 | <td>[/timeline | Fossil] |
| 52 | <td>15561 |
| 53 | <td>3764 |
| 54 | <td>1681 days<br>4.6 yrs |
| 55 | <td>2.24 |
| 56 | <td>721 MB |
| 57 | <td>18.8 MB |
| 58 | <td>38:1 |
| 59 | <td>12.0 MB |
| 60 | </tr> |
| 61 | |
| 62 | <tr align="center"> |
| 63 | <td>[http://www.sqlite.org/slt/timeline | SLT] |
| 64 | <td>2174 |
| 65 | <td>100 |
| 66 | <td>1183 days<br>3.24 yrs |
| 67 | <td>0.08 |
| 68 | <td>1.94 GB |
| 69 | <td>143 MB |
| 70 | <td>12:1 |
| 71 | <td>141 MB |
| 72 | </tr> |
| 73 | |
| 74 | <tr align="center"> |
| 75 | <td>[http://www.sqlite.org/th3.html | TH3] |
| 76 | <td>5624 |
| 77 | <td>1472 |
| 78 | <td>1248 days<br>3.42 yrs |
| 79 | <td>1.78 |
| 80 | <td>252 MB |
| 81 | <td>12.5 MB |
| 82 | <td>20:1 |
| 83 | <td>12.2 MB |
| 84 | </tr> |
| 85 | |
| 86 | <tr align="center"> |
| 87 | <td>[http://www.sqlite.org/docsrc/timeline | SQLite Docs] |
| 88 | <td>3664 |
| 89 | <td>1003 |
| 90 | <td>1567 days<br>4.29 yrs |
| 91 | <td>0.64 |
| 92 | <td>108 MB |
| 93 | <td>6.6 MB |
| 94 | <td>16:1 |
| 95 | <td>5.71 MB |
| 96 | </tr> |
| 97 | |
| 98 | </table> |
| 99 | |
| 100 | <h2>Measured Attributes</h2> |
| @@ -117,13 +110,11 @@ | |
| 117 | The "Uncompressed Size" is the total size of all the artifacts within |
| 118 | the repository assuming they were all uncompressed and stored |
| 119 | separately on the disk. Fossil makes use of delta compression between related |
| 120 | versions of the same file, and then uses zlib compression on the resulting |
| 121 | deltas. The total resulting repository size is shown after the uncompressed |
| 122 | size. For this chart, "fossil rebuild --compress" was run on each repository |
| 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | be 20% larger without that rebuild. |
| 125 | |
| 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | total number of bytes sent from server back to the client. The number of |
| 128 | bytes sent from client to server is negligible in comparison. |
| 129 | These byte counts include HTTP protocol overhead. |
| @@ -138,22 +129,20 @@ | |
| 138 | |
| 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| 143 | gets excellent 63:1 compression. SLT, on the other hand, consists of |
| 144 | many large (megabyte-sized) SQL scripts that have one or maybe two |
| 145 | edits each. There is very little delta compression occurring and so the |
| 146 | overall repository compression ratio is much lower. Note also that |
| 147 | quite a bit more bandwidth is required to clone SLT than SQLite. |
| 148 | |
| 149 | For the first nine years of its development, SQLite was versioned by CVS. |
| 150 | The resulting CVS repository measured over 320MB in size. So, the |
| 151 | developers were surprised to see that this entire project could be cloned in |
| 152 | fossil using only about 23.2MB of network traffic. (This 23.2MB includes |
| 153 | all the changes to SQLite that have been made since the conversion from |
| 154 | CVS. Of those changes are omitted, the clone bandwidth drops to 13MB.) |
| 155 | The "sync" protocol |
| 156 | used by fossil has turned out to be surprisingly efficient. A typical |
| 157 | check-in on SQLite might use 3 or 4KB of network bandwidth total, hardly |
| 158 | worth measuring. The sync protocol is efficient enough that, once cloned, |
| 159 | Fossil could easily be used over a dial-up connection. |
| 160 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -5,96 +5,89 @@ | |
| 5 | Does it use a lot of disk space or bandwidth? Is it scalable? |
| 6 | |
| 7 | In an attempt to answers these questions, this report looks at several |
| 8 | projects that use fossil for configuration management and examines how |
| 9 | well they are working. The following table is a summary of the results. |
| 10 | (Last updated on 2015-02-28.) |
| 11 | Explanation 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 2015-02-28)</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>56089 |
| 28 | <td>14357 |
| 29 | <td>5388 days<br>14.75 yrs |
| 30 | <td>3.4 GB |
| 31 | <td>45.5 MB |
| 32 | <td>73:1 |
| 33 | <td>29.9 MB |
| 34 | </tr> |
| 35 | |
| 36 | <tr align="center"> |
| 37 | <td>[http://core.tcl.tk/tcl/timeline | TCL] |
| 38 | <td>139662 |
| 39 | <td>18125 |
| 40 | <td>6183 days<br>16.93 yrs |
| 41 | <td>6.6 GB |
| 42 | <td>192.6 MB |
| 43 | <td>34:1 |
| 44 | <td>117.1 MB |
| 45 | </tr> |
| 46 | |
| 47 | <tr align="center"> |
| 48 | <td>[/timeline | Fossil] |
| 49 | <td>29937 |
| 50 | <td>8238 |
| 51 | <td>2779 days<br>7.61 yrs |
| 52 | <td>2.3 GB |
| 53 | <td>34.0 MB |
| 54 | <td>67:1 |
| 55 | <td>21.5 MB |
| 56 | </tr> |
| 57 | |
| 58 | <tr align="center"> |
| 59 | <td>[http://www.sqlite.org/slt/timeline | SLT] |
| 60 | <td>2278 |
| 61 | <td>136 |
| 62 | <td>2282 days<br>6.25 yrs |
| 63 | <td>2.0 GB |
| 64 | <td>144.7 MB |
| 65 | <td>13:1 |
| 66 | <td>142.1 MB |
| 67 | </tr> |
| 68 | |
| 69 | <tr align="center"> |
| 70 | <td>[http://www.sqlite.org/th3.html | TH3] |
| 71 | <td>8729 |
| 72 | <td>2406 |
| 73 | <td>2347 days<br>6.43 yrs |
| 74 | <td>386 MB |
| 75 | <td>15.2 MB |
| 76 | <td>25:1 |
| 77 | <td>12.6 MB |
| 78 | </tr> |
| 79 | |
| 80 | <tr align="center"> |
| 81 | <td>[http://www.sqlite.org/docsrc/timeline | SQLite Docs] |
| 82 | <td>5503 |
| 83 | <td>1631 |
| 84 | <td>2666 days<br>7.30 yrs |
| 85 | <td>194 MB |
| 86 | <td>10.9 MB |
| 87 | <td>17:1 |
| 88 | <td>8.37 MB |
| 89 | </tr> |
| 90 | |
| 91 | </table> |
| 92 | |
| 93 | <h2>Measured Attributes</h2> |
| @@ -117,13 +110,11 @@ | |
| 110 | The "Uncompressed Size" is the total size of all the artifacts within |
| 111 | the repository assuming they were all uncompressed and stored |
| 112 | separately on the disk. Fossil makes use of delta compression between related |
| 113 | versions of the same file, and then uses zlib compression on the resulting |
| 114 | deltas. The total resulting repository size is shown after the uncompressed |
| 115 | size. |
| 116 | |
| 117 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 118 | total number of bytes sent from server back to the client. The number of |
| 119 | bytes sent from client to server is negligible in comparison. |
| 120 | These byte counts include HTTP protocol overhead. |
| @@ -138,22 +129,20 @@ | |
| 129 | |
| 130 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 131 | and SLT. SQLite is a long-running project with long revision chains. |
| 132 | Some of the files in SQLite have been edited over a thousand times. |
| 133 | Each of these edits is stored as a delta, and hence the SQLite project |
| 134 | gets excellent 73:1 compression. SLT, on the other hand, consists of |
| 135 | many large (megabyte-sized) SQL scripts that have one or maybe two |
| 136 | edits each. There is very little delta compression occurring and so the |
| 137 | overall repository compression ratio is much lower. Note also that |
| 138 | quite a bit more bandwidth is required to clone SLT than SQLite. |
| 139 | |
| 140 | For the first nine years of its development, SQLite was versioned by CVS. |
| 141 | The resulting CVS repository measured over 320MB in size. So, the |
| 142 | developers were surprised to see that the equivalent Fossil project (the |
| 143 | first nine years on SQLite) would clone with only 13MB of bandwidth. |
| 144 | The "sync" protocol |
| 145 | used by fossil has turned out to be surprisingly efficient. A typical |
| 146 | check-in on SQLite might use 3 or 4KB of network bandwidth total, hardly |
| 147 | worth measuring. The sync protocol is efficient enough that, once cloned, |
| 148 | Fossil could easily be used over a dial-up connection. |
| 149 |