La difficulté de traiter ces problèmes tient principalement de l'hétérogénéité de l'ensemble. Concretement, Eclipse, la plateforme, c'est ridiculement petit, mais l'IDE Java, ou PHP, ou encore le bundle modeling, c'est des centaines de plugins qui collaborent : la cohérence technique est difficile à obtenir.
Pour donner un ordre de grandeur, Galileo c'est 24 Millions de lignes de code Java!
Un certain nombre de "bonnes pratiques" sont définies au sein du projet Eclipse pour éviter les problèmes de "temps de chargements" ou de "consommation mémoire", mais il est difficile de faire appliquer cela à cette multitude de projets.
Eclipse en lui même, par le biais d'OSGi, garanti qu'un plugin ne sera chargé que "lorsque l'utilisateur en aura besoin". Ainsi par exemple le premier démarrage d'un éditeur UML2 sera beaucoup plus long (les plugins se chargent). Malheureusement, bien que la plateforme permette en théorie de "décharger les plugins", la plupart des plugins partent de l'apriori qu'une chose chargée à un moment N, est toujours accessible à un moment N+1. Ce qui fait que généraliser le comportement du "déchargement" créerai beaucoup d'anomalie vis à vis des centaines de plugins, même externes à Eclipse.
Le conseil d'architecture d'Eclipse (Architecture Council - dont je fais partie) existe justement pour définir ces bonnes pratiques et les promouvoir.
Ne perdez pas espoir, Eclipse 4 est l'occasion d'être un peu plus strict à ce niveau là ;)
[^] # Re: Performances
Posté par Cédric Brun . En réponse à la dépêche Sortie d'Eclipse 3.5 - Galileo. Évalué à 7.
Pour donner un ordre de grandeur, Galileo c'est 24 Millions de lignes de code Java!
Un certain nombre de "bonnes pratiques" sont définies au sein du projet Eclipse pour éviter les problèmes de "temps de chargements" ou de "consommation mémoire", mais il est difficile de faire appliquer cela à cette multitude de projets.
Eclipse en lui même, par le biais d'OSGi, garanti qu'un plugin ne sera chargé que "lorsque l'utilisateur en aura besoin". Ainsi par exemple le premier démarrage d'un éditeur UML2 sera beaucoup plus long (les plugins se chargent). Malheureusement, bien que la plateforme permette en théorie de "décharger les plugins", la plupart des plugins partent de l'apriori qu'une chose chargée à un moment N, est toujours accessible à un moment N+1. Ce qui fait que généraliser le comportement du "déchargement" créerai beaucoup d'anomalie vis à vis des centaines de plugins, même externes à Eclipse.
Le conseil d'architecture d'Eclipse (Architecture Council - dont je fais partie) existe justement pour définir ces bonnes pratiques et les promouvoir.
Ne perdez pas espoir, Eclipse 4 est l'occasion d'être un peu plus strict à ce niveau là ;)