From 4f49b16079b27d7ce633619e4cddfdf2bffbc952 Mon Sep 17 00:00:00 2001 From: cashmere Date: Fri, 4 Sep 2026 09:05:24 +0200 Subject: initial commit --- www/stats.wiki | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 www/stats.wiki (limited to 'www/stats.wiki') diff --git a/www/stats.wiki b/www/stats.wiki new file mode 100644 index 0000000..285bb41 --- /dev/null +++ b/www/stats.wiki @@ -0,0 +1,149 @@ +Fossil Performance + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ProjectNumber Of ArtifactsNumber Of Check-insProject Duration
(as of 2018-06-04)		Uncompressed SizeRepository SizeCompression RatioClone 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. -- cgit v1.3.1