Repository navigation
Apply marker changes to the grid index instead of rebuilding it - #21
Merged
Merged
Conversation
MarkerGridIndex was thrown away on every add, remove or update, so the first query after any change paid the full build. An app that swaps markers on every pan paid it on its next tap and on every tile, and a drag paid it on every frame. On Android's Pixel 5a, after 300 swaps, that was 212 ms at 144,000 markers. A marker that arrives now takes the next slot, and its entry waits in a pending list; the next query sorts only those and merges them into the sorted array in one pass. A marker that leaves empties its slot, which queries skip and the next merge drops. A replacement that stays in its cell swaps the reference in its slot and nothing more. The index rebuilds only when half its slots are empty or when it cannot find a marker it was told to forget. Nothing is kept per marker to find its entry: it is in the run of the cell its position falls in, matched by identity. A marker moved in place before it is reported, as a drag does, has its entry in another cell's run; for that one the slots are scanned. The thinned query took a cell's last entry; with emptied slots it steps back to the last live one, so a cell whose representative left keeps one. Same change as MapConductor/android-sdk-core#20.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#20（K-D 木の削除）の上に積んでいる。#20 をマージしたあと、base を develop に切り替える。
MapConductor/android-sdk-core#20 と同じ変更の iOS 版。
不具合
MarkerGridIndexは、マーカーの追加・削除・更新のたびに捨てられ、次の検索が全件の作り直しを待っていた。パンのたびにマーカーを差し替えるアプリでは、次のタップとすべてのタイル描画がこれを待つ。ドラッグでは毎フレーム待つ。Android（Pixel 5a）では、300 件を差し替えた直後の検索が 14.4 万件で 212 ms だった。修正
MarkerManagerはinvalidate()の代わりにadd/remove/replaceを呼ぶ（すべて既存のロックの中）。公開 API の変更は無い（MarkerGridIndexは internal）。確認
xcodebuild build-for-testing -destination 'generic/platform=iOS'：通るシミュレータ・実機ではテストを流せていない。手元の CoreSimulator が古く、パッケージのテストはホストアプリが無いので実機では動かない。代わりに
MarkerGridIndex.swift・MarkerGrid.swift・GeoPoint.swift・GeoRectBounds.swiftをそのまま macOS 向けの SwiftPM パッケージに入れ（MarkerEntity/MarkerStateは ID・位置・同一性だけのスタブ）、MarkerGridIndexTestsを流したMac・リリースビルド、同じハーネス。日本全域に散らばるマーカー、300 件差し替え直後のクリック範囲の検索（10 回の中央値）と、ドラッグ 1 フレーム（移動＋検索、30 回の中央値）
実機では測っていない。