si j'ai un truc en background qui me mange une grosse partie de ma memoire cela ralenti tout mon traitement et ca me fait pas rire du tout.
Bah si à la place t'as un un truc en background qui à la place de bouffer de la mémoire bouffe du proc, je te garantie que ca ne va pas arranger ton temps de traitement :)
Plus sérieusement, y'a pas de mystère, indexer un grand nombre de contenu, ca consomme des ressources (mémoire de "travaille", mémoire sur disque, ressources de calcul), on a là plusieurs stratégies, elles ont toutes des avantages et des inconvénients, mais je ne suis pas sûr qu'il y en ai une de forcement meilleure : le tout est de savoir adapter cette consommation. Moi je t'ai montré que dans des environnements "conçus pour", la consommation mémoire qui bien que paraissant importante peut être paradoxalement beaucoup plus flexible en fonction des ressources de la machine. C'est pareil pour la consommation processeur : on peut bouffer beaucoup de proc, mais en étalant intelligement dans le temps cette consommation (comme il a été dit dans un commentaire juste au dessus) on peut également rendre cette consommation relativement transparente.
Bref, je pense qu'en l'état actuelle on a que des embrayons de solutions dont aucune n'est parfaite et vraiment mature, les algos et stratégies sont largement peaufinables.
Moi ce que je voulais juste faire remarquer, c'est que :
- les solutions basés sur des VM avec gestion automatique de la mémoire bouffe "naturellement" plus de mémoire, mais savent visiblement bien l'exploiter : ils n'ont pas besoin d'autant de proc que les autres solutions pour faire le même taf.
- les solutions "pure et dur" ala C/C++ qui ont une gestion moins flexible de la mémoire (en tout cas beaucoup plus manuelle et lourde si on voulait simuler le même type de comportement) font naturellement le choix d'une consommation mémoire largment moindre, mais qui est pénalisé par une plus grande consommation de CPU, ce qui là encore peut être facilement contourner par une gestion "intelligente" des ressources processeur en fonction du contexte d'utilisation de la machine.
[^] # Re: au moins un truc est clair
Posté par TImaniac (site web personnel) . En réponse au journal Etatde l'art des outils de recherches pour le bureau. Évalué à 1.
Bah si à la place t'as un un truc en background qui à la place de bouffer de la mémoire bouffe du proc, je te garantie que ca ne va pas arranger ton temps de traitement :)
Plus sérieusement, y'a pas de mystère, indexer un grand nombre de contenu, ca consomme des ressources (mémoire de "travaille", mémoire sur disque, ressources de calcul), on a là plusieurs stratégies, elles ont toutes des avantages et des inconvénients, mais je ne suis pas sûr qu'il y en ai une de forcement meilleure : le tout est de savoir adapter cette consommation. Moi je t'ai montré que dans des environnements "conçus pour", la consommation mémoire qui bien que paraissant importante peut être paradoxalement beaucoup plus flexible en fonction des ressources de la machine. C'est pareil pour la consommation processeur : on peut bouffer beaucoup de proc, mais en étalant intelligement dans le temps cette consommation (comme il a été dit dans un commentaire juste au dessus) on peut également rendre cette consommation relativement transparente.
Bref, je pense qu'en l'état actuelle on a que des embrayons de solutions dont aucune n'est parfaite et vraiment mature, les algos et stratégies sont largement peaufinables.
Moi ce que je voulais juste faire remarquer, c'est que :
- les solutions basés sur des VM avec gestion automatique de la mémoire bouffe "naturellement" plus de mémoire, mais savent visiblement bien l'exploiter : ils n'ont pas besoin d'autant de proc que les autres solutions pour faire le même taf.
- les solutions "pure et dur" ala C/C++ qui ont une gestion moins flexible de la mémoire (en tout cas beaucoup plus manuelle et lourde si on voulait simuler le même type de comportement) font naturellement le choix d'une consommation mémoire largment moindre, mais qui est pénalisé par une plus grande consommation de CPU, ce qui là encore peut être facilement contourner par une gestion "intelligente" des ressources processeur en fonction du contexte d'utilisation de la machine.