How WatchFox works
WatchFox uses a type of flat-file database. However, all transactions occur in memory. Hot datasets are kept in RAM. All I/O is what's sometimes called 'locally sequential'. That is, all reading/writing is done on non-trivial chunks sequentially (around 1-2MB).
Internally, WatchFox has three indexes, a coordinate index (x, y, z), a player index, and a time index. The coordinate index is not a combined index of three values, coordinates are compressed into a single dimension. As a result, single block transactions (generally recording and tool use) can occur very quickly, while large searches (with WorldEdit) can take significantly longer. The search time is roughly linearly dependent on the number of blocks included in the selection. That said, it's still pretty quick and it allows for use of arbitrary selections, not just cuboids.
WatchFox is also multithreaded. Internally, Bukkit will drain to a very fast queue which is then drained by a pool of slaves. WatchFox uses a locking system that's designed to scale with the number of online players, so even the busiest servers should avoid stalling issues and the most powerful of systems have room to scale. However, it does mean each online player has a distinct overhead of around 4-10 MB. This overhead does shrink as the number of players increases, however, WatchFox will not forfeit RAM to the point where it would thrash. There is no 'low memory' setting for WatchFox, it will cull cached entries to the limit of functioning by default. It does also attempt to utilize any spare memory, however 'cold' data is written out regardless to reduce the apparent memory pressure.
If none of this made sense to you, don't worry. But if you wonder why WatchFox performs as it does, this should give you enough insight to make decently accurate speculations.
Links: Home | Downloads | API Info | Changelog | How to use | What it logs | Configuration | Permission nodes | Saving | How it works | Test details | Report a bug | Validation