perf(data): paralléliser les lectures Room au démarrage + requête d’existence optimisée #7

Closed
opened 2026-06-23 20:14:15 +02:00 by CyrilLeblanc · 0 comments
Owner

Contexte

Au démarrage, deux lectures Room gaspillent du temps sur le chemin critique du premier contenu utile (arrêts/lignes) :

  • TransitRepository.isDataLoaded() (data/repository/TransitRepository.kt:86) appelle clusterDao.getAll().isNotEmpty() → charge tous les clusters en objets en mémoire, à chaque lancement, juste pour répondre oui/non.
  • StaticDataLoader.readAllStaticData() (domain/StaticDataLoader.kt:59) lit 5 tables (clusters, lines, sequences, clusterLines, geometries) en séquentiel, dont geometries est la plus volumineuse.

Objectif : réduire le temps d'apparition du premier contenu utile sur les lancements suivants (après le premier import), sans toucher au premier lancement (dominé par l'écriture).

Comportement attendu

  • isDataLoaded() → requête d'existence O(1) (SELECT EXISTS(SELECT 1 FROM clusters LIMIT 1)), plus d'allocation de la liste complète des clusters.
  • readAllStaticData() → lectures en parallèle (coroutineScope { async{} ×5 }), passage de « somme » à « max ».

Pistes d'implémentation

  • ClusterDao : ajouter @Query("SELECT EXISTS(SELECT 1 FROM clusters LIMIT 1)") suspend fun hasAny(): Boolean ; isDataLoaded() l'utilise.
  • StaticDataLoader.readAllStaticData : coroutineScope { val clusters = async { repo.getAllClusters() }; … } puis .await() sur les 5 (Room suspend → déjà sur Dispatchers.IO).
  • StaticDataResult et la signature inchangés côté appelant — pas de ripple.

Critères d'acceptation

  • isDataLoaded() n'alloue plus la liste complète des clusters.
  • Les 5 lectures de readAllStaticData s'exécutent en parallèle (même résultat pour l'appelant).
  • assembleDebug / assembleRelease OK ; aucune régression visible (carte, recherche, ETAs, plan).
  • Mesure avant/après du temps loadData() (logs temporaire retirés avant commit) sur cold start suivant — documenter le chiffre.
## Contexte Au démarrage, deux lectures Room gaspillent du temps sur le chemin critique du premier contenu utile (arrêts/lignes) : - `TransitRepository.isDataLoaded()` (`data/repository/TransitRepository.kt:86`) appelle `clusterDao.getAll().isNotEmpty()` → charge **tous** les clusters en objets en mémoire, à **chaque** lancement, juste pour répondre oui/non. - `StaticDataLoader.readAllStaticData()` (`domain/StaticDataLoader.kt:59`) lit 5 tables (clusters, lines, sequences, clusterLines, geometries) en **séquentiel**, dont `geometries` est la plus volumineuse. Objectif : réduire le temps d'apparition du premier contenu utile sur les lancements suivants (après le premier import), sans toucher au premier lancement (dominé par l'écriture). ## Comportement attendu - `isDataLoaded()` → requête d'existence O(1) (`SELECT EXISTS(SELECT 1 FROM clusters LIMIT 1)`), plus d'allocation de la liste complète des clusters. - `readAllStaticData()` → lectures en parallèle (`coroutineScope { async{} ×5 }`), passage de « somme » à « max ». ## Pistes d'implémentation - `ClusterDao` : ajouter `@Query("SELECT EXISTS(SELECT 1 FROM clusters LIMIT 1)") suspend fun hasAny(): Boolean` ; `isDataLoaded()` l'utilise. - `StaticDataLoader.readAllStaticData` : `coroutineScope { val clusters = async { repo.getAllClusters() }; … }` puis `.await()` sur les 5 (Room `suspend` → déjà sur `Dispatchers.IO`). - `StaticDataResult` et la signature inchangés côté appelant — pas de ripple. ## Critères d'acceptation - [ ] `isDataLoaded()` n'alloue plus la liste complète des clusters. - [ ] Les 5 lectures de `readAllStaticData` s'exécutent en parallèle (même résultat pour l'appelant). - [ ] `assembleDebug` / `assembleRelease` OK ; aucune régression visible (carte, recherche, ETAs, plan). - [ ] **Mesure avant/après** du temps `loadData()` (logs temporaire retirés avant commit) sur cold start suivant — documenter le chiffre.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
CyrilLeblanc/gresit#7
No description provided.