Status: Not started
kptRenderer.Render serializes the resource map into filesys.MakeFsInMemory() before render, then deserializes back afterwards. Both copies are pure overhead — the in-memory filesystem is itself backed by a map internally, but kpt doesn't expose a way to seed it or extract the underlying storage.
A map[string]string-backed implementation of filesys.FileSystem (~15 methods) would let the kpt renderer read/write directly against the resource map, eliminating both copies.
Risks:
- Path handling edge cases (
/ prefixes, . normalization, directory listing) — kpt render internals may rely on specific filesystem behaviours
- Need to synthesize directory entries from path keys
- Must validate against kpt render test suite
Acceptance Criteria:
- Investigation doc with prototype and benchmark (copy overhead vs wrapper overhead)
- Confirmed compatibility with kpt render pipeline (pass kpt's own render tests)
- Go/no-go decision on adoption
Status: Not started
kptRenderer.Renderserializes the resource map intofilesys.MakeFsInMemory()before render, then deserializes back afterwards. Both copies are pure overhead — the in-memory filesystem is itself backed by a map internally, but kpt doesn't expose a way to seed it or extract the underlying storage.A
map[string]string-backed implementation offilesys.FileSystem(~15 methods) would let the kpt renderer read/write directly against the resource map, eliminating both copies.Risks:
/prefixes,.normalization, directory listing) — kpt render internals may rely on specific filesystem behavioursAcceptance Criteria: