Mise à jour V4.035 - 03-03-2015

[Lionel57 56]

Ben en fait, je viens de scruter le code, rien de bloquant. J'ai fais le test de mon côté, dans un module virtuel, des résultats complêtements différents par rapport au même code dans une scène. Mais ça confirme ce que j'ai dit quelques pages avant, ce test ne veut absolument rien dire. Déjà  dans une scène, il suffit de modifier la valeur de l'ID testé pour obtenir des résultats totalement différent. Il suffit de lancer à  deux reprises, pour avoir également des choses différentes. Je n'avais pas testé dans un module, là , ça affiche entre 0 et 5, parce que tout ce joue dans la micro-seconde... 

[971jmd 229]

Moi tout a zéros

Envoyé de mon iPhone en utilisant Tapatalk

[Lionel57 56]

J'ai près de 150 modules, une 50aines de scènes, dont certaines communique avec mon nas, ma freebox, mon portable. Donc des trucs qui sont susceptible de ralentir la bête. Jamais ne n'ai senti le moindre ralentissement. J'ai émis des doutes, mais devant la conviction d'autres, j'ai testé. J'ai mis un ID à7, la plus haute valeur montait à5 secondes. J'ai mis un ID ) 150, la plus haute valeur montait àmoins de 3 secondes. A chaque fois, j'ai relancé le test plusieurs fois, l'écart montait jusqu'à1 à1,5 secondes avec les résultat précédent. J'ai fait le test àdans un module virtuel, suite àta remarque, tout est quasi instantanée... (0.05 secondes pour la valeur max)

[Lionel57 56]

Ceci dit, même pour 1000 itérations, le record, je l'ai vu chez Nico, avec un délai d'excution de 8 secondes. Donc pour 1 itération, ben 8 millièmes de seconde. donc normalement, pas un truc perceptible. Je persiste est signe, GEA, un truc vraiment bien pensé, mais très lourd àadapter quand le fonctionnement de la machine change. C'est pas la bête qui est trop faible, ce n'est pas la V4 qui est en cause, mais GEA qui n'est plus au point avec les évolutions successives (même si j'accorde un grand respect àson concepteur, parce que c'est rudement bien pensé)

[971jmd 229]

dans module virtuel 

finalement ça bouge très très peut

[DEBUG] 21:47:52:   Nb runs : 1000 | id : 14 | G.Variable : var22
[DEBUG] 21:47:52:   ----------------------------------------------
[DEBUG] 21:47:52:   
[DEBUG] 21:47:52:   getValue Exist      : 0s
[DEBUG] 21:47:53:   getValue Not Exist  : 1s
[DEBUG] 21:47:57:   setValue            : 4s
[DEBUG] 21:47:57:   getGlobal Exist     : 0s
[DEBUG] 21:47:57:   getGlobal Not Exist : 0s
[DEBUG] 21:47:57:   setGlobal           : 0s
[DEBUG] 21:47:57:   getType             : 0s
[DEBUG] 21:47:57:   getName             : 0s
[DEBUG] 21:47:57:   getRoomID           : 0s
[DEBUG] 21:47:57:   getRoomName         : 0s

[Lionel57 56]

Ben tu vois, ça marche... Mais ça temps à  prouver que ces valeurs ne prouvent absolument rien... Entre 0.0004 seconde pour une itération (donc 0 pour 1000 itérations) et 0.008 seconde pour une itération (donc 8 pour 1000 itérations), si tu fais la différence, c'est que tu es un grand impulsif... ;-) 

 

C'est pas la V4 qui régresse, mais GEA qui n'évolue pas (mais je précise, pas une critique, un grand respect pour son concepteur)

[971jmd 229]

pououou tout c'est itérations me donne des irritation   

[Lionel57 56]

Le LUA, ça me fait penser àl'air du config.sys et du autoexec.bat de l'époque MS-DOS, c'était grandiose, àl'époque, mais àchaque mise àjour, c'était la merde. LUA, c'est quand même un langage très très primaire, donc je pense qu'il vaut mieux privilégier plusieurs scripts basiques, plutôt que partir sur une usine àgaz, qui explosera, tôt ou tard. Mais j'admets, un grand grand truc, pour tout ceux qui ne maîtrise pas forcément, donc alléluia pour son concepteur qui a dû en ravir plus d'un

[Lionel57 56]

1000 itérations, ça veut dire que le script fait mille fois la même chose. Donc quand tu as 4 secondes pour la rubrique setvalue, ça signifie qu'il a fallu 4 secondes pour changer 1000 fois la valeur de ta variable

[971jmd 229]

ça prouve que le HC2 est largement au dessus de nos besoin

je me trompe ou pas ?

 

et que le moteur module virtuel serai plus performant que moteur des scène 

 

j'ai meme fait le test à  5000  itérations

[DEBUG] 22:17:50:   Nb runs : 5000 | id : 5 | G.Variable : var22
[DEBUG] 22:17:50:   ----------------------------------------------
[DEBUG] 22:17:50:   
[DEBUG] 22:17:50:   getValue Exist      : 0s
[DEBUG] 22:17:51:   getValue Not Exist  : 1s
[DEBUG] 22:18:12:   setValue            : 21s
[DEBUG] 22:18:13:   getGlobal Exist     : 1s
[DEBUG] 22:18:13:   getGlobal Not Exist : 0s
[DEBUG] 22:18:14:   setGlobal           : 1s
[DEBUG] 22:18:14:   getType             : 0s
[DEBUG] 22:18:15:   getName             : 1s
[DEBUG] 22:18:15:   getRoomID           : 0s
[DEBUG] 22:18:16:   getRoomName         : 1s
[DEBUG] 22:18:16:   getSunrise          : 0s
[DEBUG] 22:18:16:   
[DEBUG] 22:18:16:   ----------------------------------------------
[DEBUG] 22:18:16:   ALL DONE

Modifié 5 mars 2015 par 971jmd

[Lionel57 56]

C'est un discours que j'ai tenu tout àl'heure, c'est une bête puissante, bien au dessus de nos besoins. Si ça ralentit, faut pas chercher dans la bête, ni dans la version du code, mais dans le script en lui même (et peut être aussi ce qu'on en fait).

[971jmd 229]

si je comprend bien à  la base il y a un probleme, le moteur module virtuel serai plus performant que moteur des scène

 

il serai bien d'effectuer  le meme teste (module virtuel et scéne) sous une version 3

[Lionel57 56]

En informatique, quand on travail dans le même bloc mémoire, faire 1000 fois 1 chose ou 1 fois mille chose, c'est pareil. Mais dès qu'on travaille sur plusieurs blocs, faire 1 fois 1000 choses, ça va très très vites, par contre, faire 1000 fois 1 chose, là, ça rame

[Steven 2 335]

Pour ben Lionel57, je te laisse faire évoluer GEA puisse qu'il est disponible sur GitHub et que tu semble maitriser le sujet.

Merci d'avance pour la communauté.

Envoyé de mon portable grâce àmes petits doigts.

[Shad 315]

Bon je crois que c'est pas encore pour de suite que je ferais la MAJ en V4 XD.

[PITP2 1 593]

J'ai aussi les tests de perfs avec le script de Steven et en V4 c'est long (même ordre de grandeur que ceux qui ont déjà  fait le test)... et beaucoup plus rapide dans un VD

Steven ,tu as indiqué que tu ferais un post chez Fibaro, si tu le fais sur bugzilla tu peux nous donner son numéro nous irons abonder en ton sens pour essayer de faire bouger les développeurs de chez Fibaro.

 

PS : je ne pollue pas le post avec les copies des résultats

[Nico 2 170]

Moi j'ai la box la plus pourrie du coup :) Peut être normal, je ne suis pas passé par la 3.60 pour le moment.

 

Maintenant différents points :

-Même avec 100 modules ou 300, il faut arrêter, ce sont des requêtes très simples qui sont demandées, donc cela ne devrait pas jouer.

-Pour GEA chez moi : Jusqu'à  il y a 10 jours, comme je l'avais indiqué, moi je ne voyais pas de différence au niveau vitesse par rapport à  la V3. Depuis 10 jours, je le sens un peu pour l'allumage des lumières, et pourtant je n'ai rien modifié entre temps.

 

=> Moi je penche sur du debug à  fond qu'ils ont du rajouter pour avancer plus vite sur cette version semi stable. Quand ils vont retirer cela, on retrouvera notre puissance. Car je me répète, mais avec des requêtes aussi simple et si peut de modules, même pour les grosses installations et vu la puissance de la box, on ne devrait vraiment sentir aucune différence.

 

Maintenant en conclusion, de mon côté aucune différence dans l'utilisation de tous les jours de la box.

[kiwi 121]

@Steven: je pense savoir pourquoi le setGlobal est plus lent que le getGlobal.

 

Il faut pas oublier que la db de la HC2 est du SQLlite. La lecture de la db SQLlite peux se faire sur plein de threads en // mais par contre l'écriture de celle-ci doit nécessairement se baser avec un lock quelconque (eg un mutex ou autre par exemple) pour être sà»r que lorsque le command "COMMIT" est passée il y ait bien une cohérence dans la db.

 

Il est même probable que fibaro ajoute un "sync" pour être sà»r qu'elle soit bien écrite sur la SLC....

[Steven 2 335]

@Krikroff

 

En v4.x quand on fait un getValue() dans une scène, cela revient à  faire appel à  l'api : api.get("/devices/" .. deviceId .. "/properties/" .. propertyName)

 

Est-ce que tu sais ce qu'il en est en v3.x ?

 

Merci d'avance.

[Steven 2 335]

@kiwi

Je comprends bien ta réponse et t'en remercie, mais en 3.6, cela est pourtant beaucoup plus performant alors que la problématique est la même. Dans le cas d'un setGlobal, ils passent maintenant par l'api:put avant d’accéder àla base, je pense plus pour un problème àce niveau ci.

[Steven 2 335]

Voilà , j'ai fait mon boulot : http://bugzilla.fibaro.com/view.php?id=2965

[PITP2 1 593]

Et quel travail 

+1 sur ton post merci

[kiwi 121]

@Steven: si j'ai bien compris le truc spécifique a la version 4.x c'est que le moteur est multithreadé, dans ce cas particulier on est obligé de faire des mutex, sur la 3.x monothreadé, le bidule "sais" à  l'écriture qu'il est tout seul dessus (quitte a "oublier" des événements) donc n'as pas attendre qu'il n'y ait plus d'évenements a attendre avant d'écrire.

 

Par contre, il est possible (vu le bench là ) qu'il y ait un couille dans le pâté car les tests fait avec des HC2 sans trop de modules ont l'air lent, alors qu'on devrait avoir la même perfs (a peu de choses près) que en 3.x...

[chrispec 31]

Bonjour,

 

J'étais en 4.033 avant de passer en 4.035 hier.

 

Aujourd'hui je suis en 3.901 ?????

 

Cela vous est aussi arrivé ?

 

Le plus fort:  Tous mes modules sont absents !!!

[HANSOLO 381]

Soirée arrosée?