Memory for a whole tree: status of the Linux tree needs over 14 GB issue #35 open andymccall opened this · 0 comments
referenced by 6 changes on 29 Sep 2026
33e77a5526fa d443639bcf35 86e1824f2d0b da868d5d2646 57eaac9107df c5ce0367eddf
andymccall set labels ·
referenced by 13 changes on 29 Sep 2026
a4fad5b085c7 d3cd7ef95da6 eaf3e9068180 0554aaa7ddef 69816d688300 8b276e0106d1 206c76cad4bf 7757367bedcc 192fad1e46a2 17f94b13ae54 01a47cd7f0c8 598009a75f6c 519c7c061bcb
referenced by 16 changes on 30 Sep 2026
2c75672fb2fe f59376ea413b b493d993a9df 57d8dc05c9d4 ab4d4e31b38d d77e1702d770 4d6c9c1b358c 2517abe64654 f6451fbbae3f d0d52107b074 8457a6cc6984 75b6c8665219 e83354cdac22 dbf06d342e1d 40a40bb7b798 19527875ebdc
After issue #34 the first commit of the Linux tip (95 943 files, 1.8 GB) succeeds: 55.3 s, 9.9 GB peak, 442 MB store. A clean
oxy statusafterwards is killed by a 14 GB cap. Git needs 42 MB for the commit and 0.3 s for status. Every line is its own Vec, held in the change and again in the file graph, and status builds every graph. Measure where status spends memory, then load graphs on demand and share line bytes instead of copying them. Backlog L1b.