And here's an example of doing a checkin using libfossil's tools:

[pi@pi4b8:~/fossil/libfossil/f-apps]$ f-ci -m "Removed an unnecessary #include."
QUEUED: f-apps/f-test-ciwoco.c
New version: 681c930f1d48b809229b80f937ec54531b292240 (10052)
Note that libfossil currently has no remote sync support, so to push your changes you will need to learn the Fossil sync protocol and speak it to the remote server of your choice over a telnet connection.
Or you can just use fossil(1)'s "push" feature.

[pi@pi4b8:~/fossil/libfossil/f-apps]$ f push
Push to https://stephan@fossil.wanderinghorse.net/r/libfossil
Round-trips: 1   Artifacts sent: 2  received: 0
Push done, sent: 1035  received: 2951  ip: 173.231.209.32

[pi@pi4b8:~/fossil/libfossil/f-apps]$ f-timeline 
checkin  [681c930f1d48] @ 2021-06-25 06:26:57 by [stephan] branch [trunk] *CURRENT*

	Removed an unnecessary #include.
...

Here are the apps which do that:

• Checkin: https://fossil.wanderinghorse.net/r/libfossil/file?name=f-apps/f-ci.c
• Timeline: https://fossil.wanderinghorse.net/r/libfossil/file?name=f-apps/f-timeline.c

noting that most of the real work is done at the library level, but the applications still have a fair amount of stuff to sort out as well.

Congrats on the progress you've made so far! (Most of which I don't know how I would make use of it.)

One of the test apps does what amounts to a partial "rebuild" but, for reasons beyond my ken, it runs orders of magnitude more slowly than a rebuild using the core fossil app (i have a suspicion about the speed difference, but it's unproven).

Just to spread a little performance profiling wisdom, Stephan.

You can find most bottlenecks by casually looking at call stacks. If a routine is eating 90% of the time, then 9 times out of 10 the hotspot will be included in the call stack backtrace when you look.

This can be a very relaxing and utterly satisfying way of improving performance.

Take random, casual looks at the running process call stack and the time sucks begin to reveal themselves. This technique can be used to hone in on problems in the large and in the small. Usually. Data dependent quirks might complicate things a little bit, but the technique can help reveal those too.

Happy hunting.

Just to spread a little performance profiling wisdom, Stephan.

By all means!

You can find most bottlenecks by casually looking at call stacks. If a routine is eating 90% of the time, then 9 times out of 10 the hotspot will be included in the call stack backtrace when you look.

In this particular case the underlying algorithms were ported over 1-to-1, so the intuitive answer is that their performance is similar. The major code difference, however, is:

Fossil:

some_op();
another_op();
yet_another_op();
...

libfossil:

int rc;
rc = some_op();
if(rc) { update context's error state; goto end; }
rc = another_op();
if(rc) { update context's error state; goto end; }
rc = yet_another_op();
if(rc) { update context's error state; goto end; }
...
end:
cleanup...;
return rc;

ad nauseam. Fossil's fail-fast approach to APIs reduces explicit error handling on the part of the developer to very nearly zero in most cases. The lib API, by virtue of being a lib API, requires error checking on very nearly every line of code :/. e.g. a huge amount of fossil's work is with memory buffers, and every single change to one of those might allocate, ergo might fail to allocate, ergo requires checking its result, ergo has at least as much error checkin/handling code as business logic.

My suspicion (without having spend much time profiling it other than a few hours digging through callgrind output), is that the truly epic amount of error handling/branching is a significant factor. callgrind, however, can't really tell me whether the branching is as expensive as it seems. It can tell me CPU instruction counts, which can be compared to their counterparts in fossil, but that's a rabbit hole i have yet to go down. "First make it work, then make it fast." Aside from the so-called crosslinking (which is much of what rebuild does), the rest is/seems plenty fast (as fast as fossil, as far as us humans can perceive).

This can be a very relaxing and utterly satisfying way of improving performance.

i don't know about relaxing, but "it takes all kinds!"

Take random, casual looks at the running process call stack and the time sucks begin to reveal themselves. This technique can be used to hone in on problems in the large and in the small. Usually. Data dependent quirks might complicate things a little bit, but the technique can help reveal those too.

callgrind (a valgrind tool) and kcachegrind (a UI for the generated data) have been a big help in locating some of the hotspots, and they've been directly responsible for at least a 30-ish percent speedup in the slow parts so far.

i don't know about relaxing, but "it takes all kinds!"

Oops, wrong verb tense. s/relaxing/relaxed/. And agree, it takes more than one technique to win this game.

Plus an omission in the first reply. Glad to see you're feeling well enough to be coding, Stephan. RSI blows.

I'm not sure if any hints were dropped 8ish years ago, but there were experiments with integrating libfossil in GnuCOBOL applications when I first heard about it.

There are grand potentials in this library for programming in the large. Along with applications, I hope programming language designers catch wind of it. A programming environment with baked in self-hosted revision control and community management facilities would be a huge boon to the trade.

Have good, make well.

I'm not sure if any hints were dropped 8ish years ago, but there were experiments with integrating libfossil in GnuCOBOL applications when I first heard about it.

Not that i recall, but i have the memory of a goldfish or might have tuned out at "cobol" ;).

There are grand potentials in this library for programming in the large. Along with applications, I hope programming language designers catch wind of it. A programming environment with baked in self-hosted revision control and community management facilities would be a huge boon to the trade.

Indeed, which is why the project needs more than one active developer ;). My RSI demonstrates the very real danger of The Bus Factor. Even now, after nearly 7 years, my hands can't handle typing full time for more than a couple of months before needing a break for a month or more :/.