graham/aprs.me
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Remove completed items from TODO.md

Browse source
This commit is contained in:
Graham McIntire 2026-02-20 09:06:43 -06:00
parent f6823a70e0
commit a800910dfa
No known key found for this signature in database
1 changed files with 0 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
TODO.md
View file

@ -1,19 +1,5 @@
# Performance TODO # Performance TODO
## N+1 query in load_rf_path_station_packets
`index.ex:895` — `handle_info({:load_rf_path_station_packets, stations})` still does N+1
`Packets.get_latest_packet_for_callsign/1` calls per station. Unlike the RF path position
lookup (which only needs lat/lng), this needs full packet data for building markers with
popups. A batch version of `get_latest_packet_for_callsign` returning full packets via
`DISTINCT ON` would eliminate this.
## Batch remove_marker events
`PacketProcessor.batch_dispatch({false, true}, ...)` still pushes individual `remove_marker`
events during batch processing. These are rare (packet goes out of bounds) but could be
batched into a single `remove_markers` event with a list of IDs if profiling shows it matters.
## PostgreSQL table partitioning ## PostgreSQL table partitioning
The packets table uses CTE-based batch DELETE for cleanup (7-day retention). Time-range The packets table uses CTE-based batch DELETE for cleanup (7-day retention). Time-range
@ -25,10 +11,3 @@ time-bounded queries. This is a significant migration effort.
Changed `:aprsme` from `write_concurrency` to `read_concurrency`. The only write is Changed `:aprsme` from `write_concurrency` to `read_concurrency`. The only write is
`:message_number` increment. If message throughput increases significantly, consider using `:message_number` increment. If message throughput increases significantly, consider using
`:atomics` or `:counters` instead of ETS for the message counter. `:atomics` or `:counters` instead of ETS for the message counter.
## JS callsign→markerID reverse index
The `new_packets` handler still scans all `markerStates` when converting old markers to
historical dots. The server now sends `convert_to_historical` callsign keys which narrows
the search, but the scan is O(markerStates) in the worst case. A `Map<callsign, Set<markerId>>`
reverse index maintained by `addMarker`/`removeMarker` would make this O(1).