55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
-
+
-
+
|
- **Ticket support**. Ticket handling is surprisingly complicated, due largely to the customizability of the ticket database schema. If fossil-compatible ticket supports gets added to libfossil, it will very likely be because someone other than myself adds it! The core artifact data structure supports tickets, so the bits required for adding it are in place.
- **Decimal separator in appendf()**: maybe port in [](fossil:2cdbdbb1c9b7ad2b) to our `appendf()` impl.
# Optimizations
- Artifact crosslinking, and maybe (not yet sure) parsing, is *much* slower in libfossil than fossil. Some of this is easily attributable to more abstraction layers, but certainly not all of it. Some optimization of crosslinking speed is certainly in order. As a point of comparison, try `fossil rebuild` vs `f-parseparty --crosslink`. The latter is much, *much* slower.
- Artifact parsing, in particular of checkins, is *much* slower in libfossil than fossil. Some of this is easily attributable to more abstraction layers, but certainly not all of it. Some optimization of crosslinking speed is certainly in order. As a point of comparison, try `fossil rebuild` vs `f-parseparty --crosslink`. libf parses non-checkin types "plenty fast," e.g. 1600-odd control artifacts in roughly 6ms on my main computer. Checkins, however: 6m20s for 15504 checkins in the main fossil repo, as of this writing (just parsing, without crosslinking).
- This is at least partially (roughly 20-33%, based on basic tests) due to libfossil building in debug mode by default.
- libfossil does not have the manifest cache which fossil uses, and that *might* (might) account for a large portion of it.
- libfossil does not currently have the manifest cache which fossil uses, and that *might* (might) account for a significant portion of it.
# Remote Synchronization
- This will(?) be implemented in terms of abstract streaming APIs, very possibly the ones the library already uses for the majority of its file I/O and abstracting output streaming (e.g. it uses an abstract output stream for diff output, rather than writing directly to a buffer).
- This will almost certainly be one of the last major features.
|