Open chu11 opened 1 week ago
re-pushed fixing up a lot of the minor things listed above. I went with the general rule of making more descriptive errors when an error would be half-likely, but kept "function name: strerror" log messages for things that should extremely unlikely.
re-pushed with fixes per comments above. Also added a few new cleanups. I could probably split those out at this point in time.
Attention: Patch coverage is 73.04965%
with 38 lines
in your changes missing coverage. Please review.
Project coverage is 83.60%. Comparing base (
8015f88
) to head (91c30de
).
Files with missing lines | Patch % | Lines |
---|---|---|
src/modules/kvs-watch/kvs-watch.c | 72.66% | 38 Missing :warning: |
🚨 Try these New Features:
Problem: The FLUX_KVS_WATCH_APPEND flag is implemented inefficiently in kvs-watch. Everytime new data is appended, the entire contents of the watched key are retrieved and only new data calculated via an offset is sent to the watcher. This significantly slows down performance of large appended data (such as stdio).
Solution: Instead of retrieving the entire contents of the watched key, fetch the tree object for the key from the KVS. With access to the tree object's blobref array, we need only access the new appended blobrefs from the content store. This significantly cuts down on the amount of data transfered during a kvs-watch.
Fixes #6414
side notes:
So RPC wise the pros are:
the cons are
For large data, this is a significant performance improvement for use cases like this:
time flux run flux lptest 2000000 80
wallclock time is generally being cut down from 58 seconds to 24 seconds. It's a big win. (FWIW, this was on corona. On my laptop it was 15s before 11.7s afterwards, not as much as a win there, but still that's 22%)
For everything else (
flux job attach JOBID
for a finished job, job throughput), it appears that performance is a wash. That the wins balance out the losses. This is of course with limited testing in single node instances.Edit: Also as an aside, there is more potential for support of #6292 with this implementation