about summary refs log tree commit diff
path: root/tvix
diff options
context:
space:
mode:
authorFlorian Klink <flokli@flokli.de>2024-06-16T20·28+0300
committerflokli <flokli@flokli.de>2024-06-20T10·28+0000
commit1446e3be9991291367a2b0cd7daa1d3c0f86e8b7 (patch)
treebba4889a18714067b998c4c20a9eee079eae299b /tvix
parent8137077a747d14eaee7884ef6e59f4bcfe3d3886 (diff)
docs(tvix/docs): document nar renderer optimization potential r/8296
Change-Id: I747ab5c8ba3424828b1c88e0353170ad0efab3a6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/11849
Tested-by: BuildkiteCI
Reviewed-by: Simon Hauser <simon.hauser@helsinki-systems.de>
Diffstat (limited to 'tvix')
-rw-r--r--tvix/docs/src/TODO.md12
1 files changed, 12 insertions, 0 deletions
diff --git a/tvix/docs/src/TODO.md b/tvix/docs/src/TODO.md
index 10fb08cab0a4..a999e137066d 100644
--- a/tvix/docs/src/TODO.md
+++ b/tvix/docs/src/TODO.md
@@ -59,6 +59,18 @@ which are supposed to be skipped.
    indices into that. We might need to have different representations for small
    amount of context elements or larger ones, and need tooling to reason about
    the amount of contexts we have.
+ - To calculate NAR size and digest (used for output path calculation of FODs),
+   our current `SimpleRenderer` `NarCalculationService` sequentially asks for
+   one blob after another (and internally these might consists out of multiple
+   chunks too).
+   That's a lot of roundtrips, adding up to a lot of useless waiting.
+   While we cannot avoid having to feed all bytes sequentially through sha256,
+   we already know what blobs to fetch and in which order.
+   There should be a way to buffer some "amount of upcoming bytes" in memory,
+   and not requesting these seqentially.
+   This is somewhat the "spiritual counterpart" to our sequential ingestion
+   code (`ConcurrentBlobUploader`, used by `ingest_nar`), which keeps
+   "some amount of outgoing bytes" in memory.
 
 ### Error cleanup
  - Currently, all services use tvix_castore::Error, which only has two kinds