What problem are you trying to solve?
Lib/.../file/JSONFile.java plus AbstractArrAPI.java:249-323 - one JSON blob per (type, params), which has to be read and parsed in full to answer a question about a single item.
Most of the other memory findings follow from that one choice: the read amplification, the retained tree, the 65 MB file, the transient allocation per read. Fixing them individually helps; none of them removes the shape.
What would you like Fetcharr to do?
Newline-delimited JSON, one record per line. Reads stream, a single item costs a scan rather than a full DOM, and writes append. Minimal change to the file layer, no new dependency.
A small embedded store keyed by id. More capable, more weight, and a real dependency decision.
Either makes an incremental index viable, which is what the paged-endpoint change wants anyway - so if that direction is taken, this is likely a prerequisite rather than an alternative.
Optional additional context or use case that could be helpful
Nothing here is broken; the current design works and the per-read costs are being addressed individually. This is recorded so the individual fixes are understood as treating symptoms of one root choice, and so the decision is deliberate rather than arrived at by accretion.
What problem are you trying to solve?
Lib/.../file/JSONFile.javaplusAbstractArrAPI.java:249-323- one JSON blob per (type, params), which has to be read and parsed in full to answer a question about a single item.Most of the other memory findings follow from that one choice: the read amplification, the retained tree, the 65 MB file, the transient allocation per read. Fixing them individually helps; none of them removes the shape.
What would you like Fetcharr to do?
Newline-delimited JSON, one record per line. Reads stream, a single item costs a scan rather than a full DOM, and writes append. Minimal change to the file layer, no new dependency.
A small embedded store keyed by id. More capable, more weight, and a real dependency decision.
Either makes an incremental index viable, which is what the paged-endpoint change wants anyway - so if that direction is taken, this is likely a prerequisite rather than an alternative.
Optional additional context or use case that could be helpful
Nothing here is broken; the current design works and the per-read costs are being addressed individually. This is recorded so the individual fixes are understood as treating symptoms of one root choice, and so the decision is deliberate rather than arrived at by accretion.