| Comment: | 0.3.11: version bump and release notes |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk | version-0.3.11 |
| Files: | files | file ages | folders |
| SHA3-256: |
b1dc991ac0656b9438dafe41f3bbaee9 |
| User & Date: | dmestas on 2026-09-10 23:56:35.593 |
| Other Links: | manifest | tags |
|
2026-09-11
| ||
| 16:10 |
pull: persist only what was received, not the whole holdings store (zit#185)
A pull walked every held artifact in persistStore, reading each once from the lazy disk-backed holdings store just to early-return it: 194s of a 197s no-op pull at 1.25M artifacts, reconstructing nothing. Received artifacts are appended beyond the holdings' log-backed prefix, so persist now begins the walk there and processes only the received set. A no-op pull persists nothing; an incremental pull persists what it received, not the millions it already holds. No-op pkgsrc pull 209s to 7s. check-in: a25dcf28f5 user: dmestas tags: trunk | |
|
2026-09-10
| ||
| 23:56 | 0.3.11: version bump and release notes check-in: b1dc991ac0 user: dmestas tags: trunk, version-0.3.11 | |
| 23:42 |
serve: suppress announced igot with a set, not a scan per artifact (zit#183)
emitReply walked every held rid and, for each, linear-scanned the peer's announced list to suppress a redundant igot — O(held × announced), so a no-op pull where both sides hold everything cost 760 s of server CPU at 1.25M artifacts. Build the announced/requested names into one set per reply and probe it once per rid. ZIT reports the probe count; a test pins it to the held count at two sizes regardless of what the peer announced. check-in: a93f014321 user: dmestas tags: trunk | |