← Modification précédente Modification suivante →

Version du 31 janvier 2026 à 13:45

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉

Tests

Tests de Vincent Sylvester

Lecture écriture dans Primitems

Présentation

Depuis environ une semaine, Vincent Sylvester a mis en production le code de lecture/écriture dans Primitems.
Le code ne supprime plus toutes les lignes pour les réinsérer, il lit ce qui est là, compare et écrit les différences.
Ce code est sur la version de Vincent Sylvester, il n'est pas encore fusionné sur le tronc d'OpenSim.

Historique

Améliorations

Jusqu’à présent, aucun problème lié à cela n'a été signalé.
La différence de charge est assez remarquable.
Cela devrait accélérer la mise à jour du contenu des primitives.
Graphiques Collectd avant et après le changement :
- Premier graphique : Commandes MySQL
- Deuxième graphique : Disk Traffic

NDLR :

Vincent Sylvester a partagé les deux adresses ci-dessous, mais ces graphiques sont créés à partir des données de sa grille, en temps réel, donc les résultats partagés le jour de la réunion ne sont plus disponibles à ces adresses.

Points à clarifier

La comparaison entre les données de la scène et celles de la base de données est incertaine, c'est la seule partie qui pourrait ne pas fonctionner. Pour cela Vincent Sylvester n'a ajouté que les données que la base de données doit réellement comparer car la scène en contient davantage. C'est pour cela que ce code fait l'objet de tests plus approfondis.
Ubit Umarov signale que pour certains codes, des lectures supplémentaires de la base de données peuvent ralentir le processus, les comparaisons supplémentaire demandent plus de travail.

Reste à faire : enregistrement des modifications

Test du code de mise à jour des objets

Vincent Sylvester doit encore tester le reste du code, à savoir les modifications des objets de la scène et de l'API LSL afin de réduire le nombre d'instances d'objets marqués comme modifiés même s'ils ne le sont pas. Il faut donc plus de temps pour déboguer ce code.
Ce nouveau code lit la base de données, compare les éléments à ceux qui se trouvent dans la scène, puis ne met à jour que les éléments qui ont changé. Si la base de données contient un élément qui ne se trouve pas dans la scène, elle supprime uniquement cet élément.
Plus précisément, la mise à l'échelle des objets et le système de particules doivent faire l'objet de vérifications supplémentaires, car il y a beaucoup de scripts utilisant des timers qui ne modifient rien.
Déplacer une boule de danse avec des centaines d'animations implique la réécriture de tout ce qu'elle contient. Avec la structure actuelle du code, un simple objet physique qui se déplace déclenche des sauvegardes complètes.

Discussion

Ubit Umarov signale que la comparaison exige la lecture de toutes les données, ce qui n'est pas optimal. Il préfèrerait que cette fonctionnalité soit intégrée à la base de données pour réduire les écritures sur le disque.
De sont côté, Vincent Sylvester estime que lire les lignes pour les comparer est préférable à les supprimer et les réécrire. Les opérations d'écriture endommagent davantage les disques que les lectures. Grâce aux modifications apportées pour éviter que les éléments soient marqués comme modifiés inutilement, seules les modifications réelles devraient être lues.
Ubit Umarov dit que cette suppression en bloc est la cause d'une mauvaise conception générale qui est un peu difficile à contourner. Les sauvegardes se font par ensemble d'objets liés et il n'y a pas de moyen simple de supprimer seulement certaines primitives. Il faut tout supprimer. En fait, il pense que les bases de données le font de toute façon, même lorsqu'on modifie un seul champ.
Vincent Sylvester est d'accord sur le fait qu'il faudrait réécrire tout le code, mais pour l'instant, son approche semble être la moins destructive et la plus susceptible de fonctionner pour réduire la surcharge d'écriture. Cela permet de prolonger la durée de vie des SSD et peut même accélérer les choses sur les disques durs, car les disques ne sont pas occupés à écrire en permanence.
Ubit Umarov est d'accord sur le fait qu'il faille réduire les sauvegardes inutiles dans les bases de données.
🏗️

Informations

OSCC 2025

Petit bilan

Avacon et les bénévoles ont encore une fois fait un excellent travail. Maintenant, tout le monde attend l'oscc2026.
🏗️

Prochains événements

Il y a des événements les 13, 14 et 15 décembre:
Une fête de fin 'année est prévue mardi prochain ou mardi suivant à 15 h, heure du Pacifique, sur la grille AvaCon. Tout le monde est invité. Cela sera ajouté au calendrier.
Voir le calendrier de la conférence : https://conference.opensimulator.org/schedule/

Chiffres autour d'opensim

🏗️

Transcription en direct

🏗️

Les vidéos

James va créer les vidéos individuelles et la liste de lecture sur Youtube au cours des prochaines semaines.
Chaine Avacon sur Youtube pour l'OSCC : https://www.youtube.com/@AvaConOrg/videos
🏗️

Viewers

Dayturn

Gavin Hird est en train de déboguer des parties de son viewer.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-12-09

@@ Ligne 26 : / Ligne 26 : @@
 * Ubit Umarov signale que pour certains codes, des lectures supplémentaires de la base de données peuvent ralentir le processus, les comparaisons supplémentaire demandent plus de travail.
-===Reste à faire  ===
+===Reste à faire : enregistrement des modifications ===
-* Vincent Sylvester doit encore tester le reste du code, à savoir '''les modifications  des objets de la scène''' et à l''''API LSL''' afin de réduire le nombre d'instances d'objets marqués comme modifiés même s'ils ne le sont pas.  Il faut donc plus de temps pour déboguer ce code.
+==== Test du code de mise à jour des objets ====
-* Plus précisément, la '''mise à l'échelle des objets''' et '''le système de ''' [https://wiki.secondlife.com/wiki/Category:LSL_Particles '''particules'''] doivent faire l'objet de vérifications supplémentaires, car il y a beaucoup de scripts utilisant des [https://wiki.secondlife.com/wiki/Timer '''timers'''] qui ne modifient rien.
+* Vincent Sylvester doit encore tester le reste du code, à savoir '''les modifications  des objets de la scène''' et de l''''API LSL''' afin de réduire le nombre d'instances d'objets marqués comme modifiés même s'ils ne le sont pas.  Il faut donc plus de temps pour déboguer ce code.
+* '''Ce nouveau code lit la base de données, compare les éléments à ceux qui se trouvent dans la scène, puis ne met à jour que les éléments qui ont changé. Si la base de données contient un élément qui ne se trouve pas dans la scène, elle supprime uniquement cet élément.'''
+* Plus précisément, la '''mise à l'échelle des objets''' et '''le système de ''' [https://wiki.secondlife.com/wiki/Category:LSL_Particles '''particules'''] doivent faire l'objet de vérifications supplémentaires, car il y a beaucoup de scripts utilisant des [https://wiki.secondlife.com/wiki/Timer '''timers'''] qui ne modifient rien.
+* Déplacer une boule de danse avec des centaines d'animations implique la réécriture de tout ce qu'elle contient. Avec la structure actuelle du code, un simple objet physique qui se déplace déclenche des sauvegardes complètes.
+==== Discussion ====
+* Ubit Umarov signale que la comparaison exige la lecture de toutes les données, ce qui n'est pas optimal. Il préfèrerait que cette fonctionnalité soit intégrée à la base de données pour réduire les écritures sur le disque.
+* De sont côté, Vincent Sylvester estime que lire les lignes pour les comparer est préférable à les supprimer et les réécrire. Les opérations d'écriture endommagent davantage les disques que les lectures. Grâce aux modifications apportées pour éviter que les éléments soient marqués comme modifiés inutilement, seules les modifications réelles devraient être lues.
+* Ubit Umarov  dit que cette suppression  en bloc est la cause d'une mauvaise conception générale qui est un peu difficile à contourner. Les sauvegardes se font par ensemble d'objets liés et il n'y a pas de moyen simple de supprimer seulement certaines primitives. Il faut tout supprimer. En fait, il pense que les bases de données le font de toute façon, même lorsqu'on modifie un seul champ.
+* Vincent Sylvester est d'accord sur le fait qu'il faudrait réécrire  tout le code, mais pour l'instant, son approche semble être la moins destructive et la plus susceptible de fonctionner pour réduire la surcharge d'écriture. Cela permet de prolonger la durée de vie des [https://fr.wikipedia.org/wiki/SSD SSD] et peut même accélérer les choses sur les disques durs, car les disques ne sont pas occupés à écrire en permanence.
+* Ubit Umarov  est d'accord sur le fait qu'il faille réduire les sauvegardes inutiles dans les bases de données.
 * 🏗️