Tester sur une vieille machine, ça ne veut pas dire utiliser sur une vieille machine. L'intérêt c'est qu'on voit plus facilement qu'un programme est anormalement lent. Et le gain de performance qu'on obtient sur une vieille machine, on le retrouvera sur une neuve...
Par exemple, mettons qu'il faut 50Mo de RAM pour UN mozilla. Sur une station récente (mettons 128Mo de RAM), pas trop occupée, ça ira. Maintenant, si on voit un peu plus grand, et qu'on veut que 50 utilisateurs simultanés puissent le lancer depuis des terminaux X sur un serveur (ça fait de belles économies de matériel), on voit bien qu'il serait franchement intéressant de réduire l'occupation mémoire (2,5Go dans cet exemple, un peu moins en comptant les mappings partagés, mais l'idée est là).
On peut facilement appliquer le même exemple avec Nautilus, et il n'est certainement pas saugrenu d'envisager un /usr et un /home sur NFS dans ce genre d'environnement avec beaucoup d'utilisateurs. C'est en voyant LARGE qu'on se rend compte des gains qu'on peut obtenir en consacrant à l'optimisation un minimum du (soi-disant) précieux temps des développeurs, même pour des applications qu'on croit destinées uniquement à des utilisateurs individuels. Il faut bien comprendre que si le temps des développeurs est si précieux, c'est qu'il permet de très grosses économies à grande échelle... à condition que ce temps soit bien employé, évidemment (implémenter un cache de requêtes coûteuses est souvent plus utile qu'aligner les boutons sur un formulaire).
[^] # Re: ca fait mal...
Posté par Jean-Marc Saffroy . En réponse à la dépêche Quand Alan Cox debogue Nautilus.... Évalué à 1.
Par exemple, mettons qu'il faut 50Mo de RAM pour UN mozilla. Sur une station récente (mettons 128Mo de RAM), pas trop occupée, ça ira. Maintenant, si on voit un peu plus grand, et qu'on veut que 50 utilisateurs simultanés puissent le lancer depuis des terminaux X sur un serveur (ça fait de belles économies de matériel), on voit bien qu'il serait franchement intéressant de réduire l'occupation mémoire (2,5Go dans cet exemple, un peu moins en comptant les mappings partagés, mais l'idée est là).
On peut facilement appliquer le même exemple avec Nautilus, et il n'est certainement pas saugrenu d'envisager un /usr et un /home sur NFS dans ce genre d'environnement avec beaucoup d'utilisateurs. C'est en voyant LARGE qu'on se rend compte des gains qu'on peut obtenir en consacrant à l'optimisation un minimum du (soi-disant) précieux temps des développeurs, même pour des applications qu'on croit destinées uniquement à des utilisateurs individuels. Il faut bien comprendre que si le temps des développeurs est si précieux, c'est qu'il permet de très grosses économies à grande échelle... à condition que ce temps soit bien employé, évidemment (implémenter un cache de requêtes coûteuses est souvent plus utile qu'aligner les boutons sur un formulaire).