Pour le nombre important de fichiers lus, il s'agit du cas ou tu lances ton bureau. Il faut activer un certain nombre de services (dans le cas KDE: kwin, kicker, ksycoca=surveillance des fichiers de config, kdesktop, kdcop, splash screen), chacun avec son fichier de conf et restaurer toutes les applications de ta session precedente. Tout le temps gagne a ce moment la te donnera une tres grande satisfaction des utilisateurs en terme de "desktop X se lance vachement vite quand je me logge".
> Le configuration est lu une fois au début et c'est tout.
Non. D'une part, le simple fait de lire la configuration peut-etre une operation complexe. Typiquement sous KDE, tu as un setting system dans $KDEDIR/config/myapp/myapp.rc que tu peux surcharger avec un setting utilisateur $HOME/.kde/config/myapp/myapp.rc
Tu peux rajouter d'autres repertoires contenant des settings (suffit de les rajouter a $KDEDIRS) pour surcharger les settings systemes avant d'arriver aux settings utilisateurs.
Pour une application donnee, il se peut aussi que les settings soient repartis dans plusieurs fichiers de config. C'est notamment le cas quand tu vas utiliser un composant kpart. Par exemple kontact (l'equivalent d'evolution) va lire des setting kontact, des settings kmail et va lire aussi ta liste de contacts et no de telephones qui se situera ailleurs.
La configuration est aussi susceptible d'etre relue. Typiquement, quand tu fais 'appliquer' sur un panneau de config, tous les applications utilisant ce jeu de parametres sont notifiees qu'il a evolue et qu'il faut donc le relire.
Bref, c'est loin d'etre aussi simpliste qu'on pourrait le penser initialement.
Je me souviens que pour KDE 2, Waldo Bastian avait fait une grosse passe la-dessus et avait trouve par exemple que il est plus rapide de lire un fichier texte tout d'un coup plutot que ligne par ligne, et que il ne faut faire la conversion unicode que si on a besoin d'une chaine traduite. Ce genre d'optimisation avait permis de gagner quelques dizaines de secondes par ci par la, et en tout, c'est plusieurs secondes d'economisees.
En terme de temps de demarrage, tout est a prendre parce que l'utilisateur appreciera beaucoup.
[^] # Re: Un fork pour un gnome d'expert
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 6.
> Le configuration est lu une fois au début et c'est tout.
Non. D'une part, le simple fait de lire la configuration peut-etre une operation complexe. Typiquement sous KDE, tu as un setting system dans $KDEDIR/config/myapp/myapp.rc que tu peux surcharger avec un setting utilisateur $HOME/.kde/config/myapp/myapp.rc
Tu peux rajouter d'autres repertoires contenant des settings (suffit de les rajouter a $KDEDIRS) pour surcharger les settings systemes avant d'arriver aux settings utilisateurs.
Pour une application donnee, il se peut aussi que les settings soient repartis dans plusieurs fichiers de config. C'est notamment le cas quand tu vas utiliser un composant kpart. Par exemple kontact (l'equivalent d'evolution) va lire des setting kontact, des settings kmail et va lire aussi ta liste de contacts et no de telephones qui se situera ailleurs.
La configuration est aussi susceptible d'etre relue. Typiquement, quand tu fais 'appliquer' sur un panneau de config, tous les applications utilisant ce jeu de parametres sont notifiees qu'il a evolue et qu'il faut donc le relire.
Bref, c'est loin d'etre aussi simpliste qu'on pourrait le penser initialement.
Je me souviens que pour KDE 2, Waldo Bastian avait fait une grosse passe la-dessus et avait trouve par exemple que il est plus rapide de lire un fichier texte tout d'un coup plutot que ligne par ligne, et que il ne faut faire la conversion unicode que si on a besoin d'une chaine traduite. Ce genre d'optimisation avait permis de gagner quelques dizaines de secondes par ci par la, et en tout, c'est plusieurs secondes d'economisees.
En terme de temps de demarrage, tout est a prendre parce que l'utilisateur appreciera beaucoup.