Disons que j'ai plus qu'une observation :
- j'observe que wicd me prend un gros pourcentage de temps CPU.
- j'observe ussi que sur mon fixe, il arrive à hp-systray de me faire la même chose
- les deux sont écrits en python
- a chaque fois que j'ai vu ma batterie se décharger anormalement vite, wicd prenait beaucoup de temps CPU, bien plus que les onglets Firefox ouverts.
De plus :
- il est reconnu qu'un programme python s'exécute plus lentement (parfois beraucoupo plus lentement selon le programme) que le même programme écrit dans un langage compilé - exemple: le C). Mais ce problème ne concerne pas que Python: un site écrit en Ruby/Rails est assez lent (parfois plus lent qu'un site écrit en python). Le seul à bien s'en sortir à ce niveau (à ma connaissance), c'est le Perl ( dans une de mes missions, un outil avait été écrit en Perl plutôt qu'en python car Python s'en sortait pas niveau perfs). Et je ne parle pas de PHP qui n'a pas forcément une bonne réputation (mais que je ne connais plus suffisamment pour en parler). La lenteur ne vient pas du fait que les cycles CPU sont plus lent à s'exécuter pour un probramme python ou Ruby que pour un programme Perl ou C. Le fait est bien que Python ou Ruby utilisent plus de cycle CPU (donc plus d'énergie).
Et je pousse ma réflexion en me disant que l'économie d'énergie n'est pas juste un priblème de portable, mais qu'elle concerne aussi les serveurs. Et qu'un jour on devra probablement remettre en question nos façons de faire. Peut-être n'ira-t-on pas jusqu'à utiliser de l'asselmbleur partout (pour caricvaturer un peu), mais a mon avis ça passera au moins par un gros travail sur les perfs des runtimes des langages tels que Python, Ruby ou PHP.
Donc oui, ça me fait peur d'avoir un démon python qui s'exécute sur une machine qui a besoin d'éconoimiser de l'énergie. Alors effectivement, dans le cas présent, ça ne pose probablement pas problème puisque le programme attend des evenements clavier. Par contre je ne suis pas sur que ce soit aussi neutre pour un prog qui fait du pooling à intervales réguliers par exemple, intervalles suffisamment proches pour que le code soit sollicité souvent). Maintenant mon raisonnement n'est peut-être pas bon, j'en ai conscience, ou je le pousse peut-être un peu trop. Mais dans ce cas, j'apprécie d'avantage ta démarche, qui consiste à me faire expliquer mon point de vue, pour me corriger si nécessaire, que celle de certains autres intervenant (un en particulier).
[^] # Re: quand je vois "demon système en python"...
Posté par totof2000 . En réponse au journal Mini-projet (python): un démon système pour gérer des raccourcis clavier. Évalué à 0. Dernière modification le 19 août 2019 à 08:55.
Disons que j'ai plus qu'une observation :
- j'observe que wicd me prend un gros pourcentage de temps CPU.
- j'observe ussi que sur mon fixe, il arrive à hp-systray de me faire la même chose
- les deux sont écrits en python
- a chaque fois que j'ai vu ma batterie se décharger anormalement vite, wicd prenait beaucoup de temps CPU, bien plus que les onglets Firefox ouverts.
De plus :
- il est reconnu qu'un programme python s'exécute plus lentement (parfois beraucoupo plus lentement selon le programme) que le même programme écrit dans un langage compilé - exemple: le C). Mais ce problème ne concerne pas que Python: un site écrit en Ruby/Rails est assez lent (parfois plus lent qu'un site écrit en python). Le seul à bien s'en sortir à ce niveau (à ma connaissance), c'est le Perl ( dans une de mes missions, un outil avait été écrit en Perl plutôt qu'en python car Python s'en sortait pas niveau perfs). Et je ne parle pas de PHP qui n'a pas forcément une bonne réputation (mais que je ne connais plus suffisamment pour en parler). La lenteur ne vient pas du fait que les cycles CPU sont plus lent à s'exécuter pour un probramme python ou Ruby que pour un programme Perl ou C. Le fait est bien que Python ou Ruby utilisent plus de cycle CPU (donc plus d'énergie).
Et je pousse ma réflexion en me disant que l'économie d'énergie n'est pas juste un priblème de portable, mais qu'elle concerne aussi les serveurs. Et qu'un jour on devra probablement remettre en question nos façons de faire. Peut-être n'ira-t-on pas jusqu'à utiliser de l'asselmbleur partout (pour caricvaturer un peu), mais a mon avis ça passera au moins par un gros travail sur les perfs des runtimes des langages tels que Python, Ruby ou PHP.
Donc oui, ça me fait peur d'avoir un démon python qui s'exécute sur une machine qui a besoin d'éconoimiser de l'énergie. Alors effectivement, dans le cas présent, ça ne pose probablement pas problème puisque le programme attend des evenements clavier. Par contre je ne suis pas sur que ce soit aussi neutre pour un prog qui fait du pooling à intervales réguliers par exemple, intervalles suffisamment proches pour que le code soit sollicité souvent). Maintenant mon raisonnement n'est peut-être pas bon, j'en ai conscience, ou je le pousse peut-être un peu trop. Mais dans ce cas, j'apprécie d'avantage ta démarche, qui consiste à me faire expliquer mon point de vue, pour me corriger si nécessaire, que celle de certains autres intervenant (un en particulier).