vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2024-02-06T12:01:30+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/5243Speed up users page2024-02-06T12:01:30+01:00CHESNIN ClementSpeed up users pagePour le moment, l'ouverture de la page users sur app met 30s...
Quelques idées :
- voir si on peut optimiser les requêtes sb
- paginer la réponse (cf ce qu'on a fait pour les sample_sets)
- avoir un chargement dynamique des infos sur les...Pour le moment, l'ouverture de la page users sur app met 30s...
Quelques idées :
- voir si on peut optimiser les requêtes sb
- paginer la réponse (cf ce qu'on a fait pour les sample_sets)
- avoir un chargement dynamique des infos sur les users
- ...Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5041Bibliothèque SIMD alignement .js/.py pour comparaison de clonotypes ?2022-06-17T12:39:29+02:00Mathieu GiraudBibliothèque SIMD alignement .js/.py pour comparaison de clonotypes ?
Pas (encore) pour remplacer dynprog, mais au moins pour utilisation client en comparaison de séquences, sans assignation VDJ.
Pas (encore) pour remplacer dynprog, mais au moins pour utilisation client en comparaison de séquences, sans assignation VDJ.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4856Primers; rendre la fonction de positionnement asynchrone2021-10-06T14:13:11+02:00Thonier FlorianPrimers; rendre la fonction de positionnement asynchroneC'est parfois long, et frustrant de bloquer entièrement le client sur l'appel de cette fonction.
On devrait pouvoir rendre son appel asynchrone.C'est parfois long, et frustrant de bloquer entièrement le client sur l'appel de cette fonction.
On devrait pouvoir rendre son appel asynchrone.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4800Temps de calcul Genescan2021-05-19T12:08:18+02:00Mathieu GiraudTemps de calcul GenescanUn cas avec 16 patients x 100 clones qui prend 3-4 minutes.
Mais bon... on ne conseille pas d'analyser les patients individuellement sur une telle vue.
- des choses possibles pour accélérer ?
- sinon, limiter l'utilisation de cet axe ?Un cas avec 16 patients x 100 clones qui prend 3-4 minutes.
Mais bon... on ne conseille pas d'analyser les patients individuellement sur une telle vue.
- des choses possibles pour accélérer ?
- sinon, limiter l'utilisation de cet axe ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4347Optimisation du chargement des distributions2020-07-28T11:18:44+02:00Thonier FlorianOptimisation du chargement des distributionsLes distributions sont sources de ralentissement lors du chargement des analyses.
Je cherche un moyen d’accélérer cette latence induite. Parfois quelques dizaine de secondes de perte de contrôle de l'interface, et en plus, un message d...Les distributions sont sources de ralentissement lors du chargement des analyses.
Je cherche un moyen d’accélérer cette latence induite. Parfois quelques dizaine de secondes de perte de contrôle de l'interface, et en plus, un message du navigateur aux utilisteurs indiquant un possible `freeze`.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4303Waiting for server reply / still waiting alors que le .vidjil est chargé2020-06-12T20:44:03+02:00Mathieu GiraudWaiting for server reply / still waiting alors que le .vidjil est chargé
J'ai un message "still waiting...", sur deux navigateurs différents, sur Demo : https://app.vidjil.org/browser/?set=3241&config=25
Ce qui est curieux est que je pense déjà avoir récupéré le `.vidjil`, quasi tout s'affiche, je peux util...
J'ai un message "still waiting...", sur deux navigateurs différents, sur Demo : https://app.vidjil.org/browser/?set=3241&config=25
Ce qui est curieux est que je pense déjà avoir récupéré le `.vidjil`, quasi tout s'affiche, je peux utiliser certaines fonctionnalités... de toute manière, tant qu'on n'a pas tout récupéré le `.vidjil`, rien ne se passe ?
Cela vient peut-être de ma machine/connexion, mais, même dans ce cas, il faudrait comprendre ce qu'il se passe.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4146Surveiller par CI des mesures de temps2020-01-21T16:39:22+01:00Mathieu GiraudSurveiller par CI des mesures de tempsExtrait de #2196 (mais pourrait aussi s'appliquer à ~"cpp-speed" et ~"server-speed"):
> Idéalement, un jour on aimerait (...) surveiller cela par ~"dev-ci".
> Un test sur un slave fixe, et trouver comment indiquer cela (un temps en dur...Extrait de #2196 (mais pourrait aussi s'appliquer à ~"cpp-speed" et ~"server-speed"):
> Idéalement, un jour on aimerait (...) surveiller cela par ~"dev-ci".
> Un test sur un slave fixe, et trouver comment indiquer cela (un temps en dur dans un fichier, et le test plante si +/- 10%) ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4145Remplacer les sleep de Watir par un test sur le nouveau flag2022-03-23T13:48:51+01:00Mathieu GiraudRemplacer les sleep de Watir par un test sur le nouveau flagmerci Marc pour cette proposition :)merci Marc pour cette proposition :)https://gitlab.inria.fr/vidjil/vidjil/-/issues/4141Chargement très long depuis le hotfix2020-01-21T13:50:40+01:00Mikaël SalsonChargement très long depuis le hotfixSur ma machine j'ai un fichier .vidjil (et .analysis) pour L3 que je charge automatiquement quand j'accède au client en local.
Là je viens de remarquer que c'était trèèèèès long à charger. Après mesure cela a mis 1m30 contre quasi imméd...Sur ma machine j'ai un fichier .vidjil (et .analysis) pour L3 que je charge automatiquement quand j'accède au client en local.
Là je viens de remarquer que c'était trèèèèès long à charger. Après mesure cela a mis 1m30 contre quasi immédiat avant. Un git bisect me donne 76433f4.
J'aurais tendance à penser que c'est la cause de #4140.
cc @duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4112Initialisation "Vidjil is loading" / splash screen2020-08-04T09:28:11+02:00Mathieu GiraudInitialisation "Vidjil is loading" / splash screenÉvoqué avec @duez : pour l'instant, rien de vraiment propre à l'init, cela peut prendre du temps, entre la latence du serveur et l'initialisation de l'ensemble. Faire patienter joliment nos usagers.Évoqué avec @duez : pour l'instant, rien de vraiment propre à l'init, cela peut prendre du temps, entre la latence du serveur et l'initialisation de l'ensemble. Faire patienter joliment nos usagers.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4086Améliorer l'efficacité de la liste2019-12-06T16:37:41+01:00Mikaël SalsonAméliorer l'efficacité de la liste@duez : "Lorsqu'on fait un updateElem sur la liste on consulte le DOM pour regarder s'il faut changer des choses : c'est coûteux. L'idée serait de stocker le `div` comme un attribut pour n'accéder au DOM que s'il faut réellement modifier...@duez : "Lorsqu'on fait un updateElem sur la liste on consulte le DOM pour regarder s'il faut changer des choses : c'est coûteux. L'idée serait de stocker le `div` comme un attribut pour n'accéder au DOM que s'il faut réellement modifier l'élément" [Marc n'hésite pas à corriger si j'ai fait un contre sens]https://gitlab.inria.fr/vidjil/vidjil/-/issues/4085Améliorer l'efficacité de l'aligneur2021-04-08T08:31:50+02:00Mikaël SalsonAméliorer l'efficacité de l'aligneurLorsqu'on sélectionne beaucoup de clones, le segmenteur rame pour les ajouter.
@duez a des idées pour améliorer cela. L'idée serait de précharger toutes les séquences dans le segmenteur (le volume de données et la quantité de tags me fa...Lorsqu'on sélectionne beaucoup de clones, le segmenteur rame pour les ajouter.
@duez a des idées pour améliorer cela. L'idée serait de précharger toutes les séquences dans le segmenteur (le volume de données et la quantité de tags me fait un peu peur, mais Marc a l'air serein !) pour éviter d'avoir à ajouter (et supprimer) plein de choses à la volée.
Des tests à mener, déjà pour voir si une machine modeste tient bien le choc en insérant tout d'un coup.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4077Chargement des distributions trop long ?2020-06-11T15:35:13+02:00Mathieu GiraudChargement des distributions trop long ?@flothoni : "Plus long qu'avant ?"
Par exemple le dernier fichier d'exemple disponible sur les environnements de review, environ 900 clones, 250 réels, 650 de distributions@flothoni : "Plus long qu'avant ?"
Par exemple le dernier fichier d'exemple disponible sur les environnements de review, environ 900 clones, 250 réels, 650 de distributionsDéploiement 2020.06https://gitlab.inria.fr/vidjil/vidjil/-/issues/3975Lors d'un hover on reparcourt la liste des clones (updateElemStyle)2019-12-26T11:43:38+01:00Mikaël SalsonLors d'un hover on reparcourt la liste des clones (updateElemStyle)Comme indiqué dans #3903, il suffit d'un hover sur un clone pour reparcourir plusieurs fois la liste des clones. Cela ne semble pas nécessaire à priori.
Dans `focusIn` dans `model.js` on fait bien ce qu'il faut : on met à jour le clone ...Comme indiqué dans #3903, il suffit d'un hover sur un clone pour reparcourir plusieurs fois la liste des clones. Cela ne semble pas nécessaire à priori.
Dans `focusIn` dans `model.js` on fait bien ce qu'il faut : on met à jour le clone concerné :
```js
this.updateElemStyle([cloneID]);
```
C'est donc (a priori) une mise à jour légère. Sauf qu'il y a un hic dans `updateElemStyle` :
```js
this.updateModel();
```
Boum… on fait un updateModel(). Cela date de 2014, on peut essayer de le retirer mais j'ai quand même quelques doutes.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3895Comparer dans le client beaucoup de samples d'un coup2019-12-13T12:26:11+01:00Mathieu GiraudComparer dans le client beaucoup de samples d'un coup@Anne, dans https://gitlab.inria.fr/vidjil/vidjil/issues/3889#note_187960 :
> la visualisation par run est aussi un peu longue à ouvrir et pas très facile à manier (65 samples dans mon dernier run)
Oui ! C'est dommage. Nous avons des c...@Anne, dans https://gitlab.inria.fr/vidjil/vidjil/issues/3889#note_187960 :
> la visualisation par run est aussi un peu longue à ouvrir et pas très facile à manier (65 samples dans mon dernier run)
Oui ! C'est dommage. Nous avons des choses en cours de développement pour avoir une vue d'ensemble sur un run via une page du ~server (~"server\-qc\-stats"), mais on pourrait se demander ce qu'on pourrait voir depuis le ~client.
L'axe `number of samples sharing each clone` peut être utile. Voir par exemple http://app.vidjil.org/?set=30982&config=2&plot=v,nbSamples,grid&clone=7,25,166 , ici au moins trois clones se trouvent dans au moins 10 samples.
Y aurait-il un moyen de mieux voir cela ?
- limiter le ~"client\-graph" ? À un moment, on n'affichait qu'au plus 20 samples (mais c'était ~"server\-fuse"). Cela pourrait être une limitation soft, ou les données sont présentes et on se contente de cacher (dans l'épingle à droite) des choses (serait-ce plus rapide ?)
- enlever complètement le ~"client\-graph" ? (mais comment indiquer clairement qu'on visualise alors un sample ? mettre en valeur le nom du sample en haut à gauche ?)
- avoir par défaut une vue ~"client\-grid" avec l'axe `nbSamples` ? (~"!\-easy") Si on enlève le ~"client\-graph", on pourrait avoir cette vue en plus de la ~"client\-grid" habituelle.
- avoir une autre vue faite pour cela, qui remplace le ~client-graph et qui donne un "résumé" lisible (type #1887) ? (~"!\-hard")
cc @flothoni @mikael\-s
~"client\-axis"https://gitlab.inria.fr/vidjil/vidjil/-/issues/3437d3.js : conserver, changer ?2019-01-10T15:21:24+01:00Mathieu Giraudd3.js : conserver, changer ?Conservera-t-on a terme d3.js ? Très puissant, mais maitrise-t-on ce qu'il se passe ?
chart.js va être testé par @flothoni pour ~"app\-stats" stats#233, on pourra ainsi se faire une idée.
(Notons que même le ~"client\-grid" pourrait êtr...Conservera-t-on a terme d3.js ? Très puissant, mais maitrise-t-on ce qu'il se passe ?
chart.js va être testé par @flothoni pour ~"app\-stats" stats#233, on pourra ainsi se faire une idée.
(Notons que même le ~"client\-grid" pourrait être fait en chart.js, http://www.chartjs.org/samples/latest/scriptable/bubble.html). Mais chart.js ne permet pas d'export svg.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3181Lancer CloneDB depuis fuse.py ou en offline2019-02-14T18:19:54+01:00Mathieu GiraudLancer CloneDB depuis fuse.py ou en offlineExtrait de #2312 et clonedb#1 :
> Lancer la cloneDB sur tous les clones côté client peut être une mauvaise idée ! (à voir si on le fait dans le `fuse.py`).
Pourquoi pas... mais dans ce cas, pas de check sur la contamination intra-run #...Extrait de #2312 et clonedb#1 :
> Lancer la cloneDB sur tous les clones côté client peut être une mauvaise idée ! (à voir si on le fait dans le `fuse.py`).
Pourquoi pas... mais dans ce cas, pas de check sur la contamination intra-run #1744 (qui pourrait être fait séparément).
À voir aussi comment on indique que cela a été fait "à une certain moment" (et donc, si on revient plus tard, pas forcément à jour). Et/ou relancer périodiquement CloneDB sur le serveur ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3113Performance highlights feature-c/segmenter_highlights2018-07-05T09:37:49+02:00Ryan HerbertPerformance highlights feature-c/segmenter_highlightsPour logger un peu les résultats de mes tests.
Performances de `highlightToString`:
- Sans highlight seq (comportement avant refactor): 0.5-2 ms/clone
- Avec highlight seq (4 highlights à séquence): 5-15 ms/clone
Si on aligne les séquen...Pour logger un peu les résultats de mes tests.
Performances de `highlightToString`:
- Sans highlight seq (comportement avant refactor): 0.5-2 ms/clone
- Avec highlight seq (4 highlights à séquence): 5-15 ms/clone
Si on aligne les séquences, on passe à envviron 30 ms/clone
https://gitlab.inria.fr/vidjil/vidjil/-/issues/2786tsne.js prend un peu de temps2022-06-17T12:39:29+02:00Thonier Floriantsne.js prend un peu de tempsEn regardant le tuto, j'ai remarqué que cette fonction ne marchait plus; En effet, le script rentre dans une boucle infinie.
Cela ce voit sur le sample `demo lil3`, avec le choix des `plot by similarity`. L'erreur retourne à la `ligne ...En regardant le tuto, j'ai remarqué que cette fonction ne marchait plus; En effet, le script rentre dans une boucle infinie.
Cela ce voit sur le sample `demo lil3`, avec le choix des `plot by similarity`. L'erreur retourne à la `ligne 332` ou bien `345`.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2771Le découpage des méthodes "update" est-il judicieux ?2017-11-08T09:47:11+01:00Ryan HerbertLe découpage des méthodes "update" est-il judicieux ?Les vues JS ont plusieurs méthodes de mise à jour:
- `update`
- `updateElem`
- `updateStyle`
- `updateElemStyle`
Ce découpage peut avoir beaucoup de sens pour optimiser l'application, et réduire le nombre d'opérations inutiles. Comm...Les vues JS ont plusieurs méthodes de mise à jour:
- `update`
- `updateElem`
- `updateStyle`
- `updateElemStyle`
Ce découpage peut avoir beaucoup de sens pour optimiser l'application, et réduire le nombre d'opérations inutiles. Comme par exemple, la sélection d'un clone n'affecte que son esthétique, donc on applique `updateElemStyle` pour indiquer aux vues de modifier le style du clone sélectionné.
En revanche, dans certaines situations, celà peut poser des problèmes. Je pense notamment à url.js, qui a besoin de connaître les changements de sélection de clones, ainsi que d'autres changements non-cosmetiques. Appliquer le même paradigme de `update` et `updateElemStyle`... pose un soucis de duplication des tâches. D'une part les deux méthodes seront les mêmes, mais appliquées à différents types de paramètres, et d'autre part on se retrouve avec une duplication de URL.pushState (problème similaire à #2438 ).