Where
arena/app.py — _append_vote_record_unlocked(), _update_meta_log_unlocked() (line ~435), _write_json_file().
Problem
Per submitted vote, the persistence path:
- Reads all of
votes.json into memory, appends one record, and rewrites the entire file (_append_vote_record_unlocked), with fsync + atomic replace.
- Reads all of
arena_logs/meta.json, appends to round_summaries, and rewrites the whole file.
Both files grow without bound (round_summaries duplicates data already persisted per-session in arena_logs/sessions/<...>/round.json, and the repo's own sample votes.json was already 75 KB). Cost per vote is O(total history), so submissions get progressively slower and the read-modify-write window (even with the file locks) grows.
Additionally, _leaderboard_view_data() re-reads and re-parses the full meta.json on every page load and every vote submission just to rebuild the same rows.
Suggested fix (pick pragmatically)
- Store votes as JSON Lines (
votes.jsonl): appending a vote becomes an O(1) append of one line, still crash-tolerant, no read-modify-write.
- In
meta.json, keep only the aggregates (model_totals, total_rounds) and drop round_summaries — the per-session round.json/vote.json files already contain everything a summary would need, and nothing in the app reads round_summaries.
- (Optional) Cache the parsed leaderboard and invalidate on vote submission instead of re-reading the file on every
demo.load.
This is a local-first app so none of this is urgent, but the current design has a built-in slowdown curve and stores every round in three places.
Where
arena/app.py—_append_vote_record_unlocked(),_update_meta_log_unlocked()(line ~435),_write_json_file().Problem
Per submitted vote, the persistence path:
votes.jsoninto memory, appends one record, and rewrites the entire file (_append_vote_record_unlocked), withfsync+ atomic replace.arena_logs/meta.json, appends toround_summaries, and rewrites the whole file.Both files grow without bound (
round_summariesduplicates data already persisted per-session inarena_logs/sessions/<...>/round.json, and the repo's own samplevotes.jsonwas already 75 KB). Cost per vote is O(total history), so submissions get progressively slower and the read-modify-write window (even with the file locks) grows.Additionally,
_leaderboard_view_data()re-reads and re-parses the fullmeta.jsonon every page load and every vote submission just to rebuild the same rows.Suggested fix (pick pragmatically)
votes.jsonl): appending a vote becomes an O(1) append of one line, still crash-tolerant, no read-modify-write.meta.json, keep only the aggregates (model_totals,total_rounds) and dropround_summaries— the per-sessionround.json/vote.jsonfiles already contain everything a summary would need, and nothing in the app readsround_summaries.demo.load.This is a local-first app so none of this is urgent, but the current design has a built-in slowdown curve and stores every round in three places.