Aller au contenu

Messages recommandés

Posté(e)

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... 

Posté(e)

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)

Posté(e)

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é)

Posté(e)

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

Posté(e)

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)

Posté(e)

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

Posté(e)

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

Posté(e) (modifié)

ç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é par 971jmd
Posté(e)

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).

Posté(e)

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

Posté(e)

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

Posté(e)

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.

Posté(e)

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

Posté(e)

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.

Posté(e)

@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....

Posté(e)

@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.

Posté(e)

@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.

Posté(e)

@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...

  • Upvote 1
Posté(e)

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 !!!

×
×
  • Créer...