I've got a test repo partly converted from git which has 12 directories containing 806 files and 25Mb of code. Recording while profiling with callgrind shows that the nested self.iter_nodes loops eat up much of the time. For example, recording a 10 line change across 3 files takes 63 seconds. Commenting out the two calls to confirm_path reduces that to 21 seconds.
From the profile it seems that confirm_path ends up calling the node-iterator's next method about 750k times per file.
This should be fixed in master, but I'm not good at reading the output of callgrind. Would you be able to check?
Thanks. This may take a while to test as the newer version of pijul is giving a NoDB error for my test repo and the main git-pijul doesn't build against the latest libpijul
you can fix the nodb error by running "pijul record", even if there's nothing to record, it will unlock the issue
Unfortunately that just gives this error and doesn't fix the NoDB:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21
9: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
10: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
11: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::record
Well, I've patched git-pijul for this version of libpijul but can't seem to get valgrind to read the debug info.
The good news is that it's much faster, around 10 times based on wall clock and perf shows that graph::retrieve and record::diff_with_binary pretty equally share the remaining time.
If anyone's interested here's the perf graph
Has this been fixed?