Visual Studio 2010 : la vitesse de la prochaine béta fortement améliorée par les développeurs de Microsoft
Le 2009-08-25 13:17:51, par Gordon Fowler, Expert éminent sénior
La première béta de Visual Studio 2010, la suite de logiciels de développement pour Windows sortie en Mai dernier, avait essuyé de nombreuses critiques de la part des utilisateurs.
Depuis, les responsables du projet chez Microsoft ont décidé de les écouter et tentent depuis plusieurs mois d'améliorer les performances de leurs logiciels.
La faiblesse la plus montrée du doigt a été la vitesse.
Sur ce point, Rico Mariani, un des membres les plus influents de l'équipe de développeurs, confie sur son blog que le multi-threading a été au centre de ses préoccupations :
…the product is a lot more multi-threaded than previous versions and in some cases synchronization between threads was less than great.
Weston Hutchins, responsable de projet dans l'équipe, confirme.
Pour lui, le problème de la vitesse n'est encore que partiellement réglé, notamment au moment du lancement des logiciels.
Néanmoins, Visual Studio 2010 resterait pour l'instant plus lent que sa mouture précédente de 2008.
Il s'en explique :
La manière d''utiliser la mémoire pour accroitre les performances devrait donc au être cœur des prochaines améliorations.
Rico Mariani avoue d'ailleurs être déjà au travaille.
Il détaille ces futurs travaux dans un billet très complet où il fait le bilan de l'avancement du projet :
Et de conclure, optimiste, que le produit est pour lui d'ores et déjà "beaucoup, beaucoup mieux".
Mais est-il bon ?
Source :
Lire aussi :
Et vous :
Depuis, les responsables du projet chez Microsoft ont décidé de les écouter et tentent depuis plusieurs mois d'améliorer les performances de leurs logiciels.
La faiblesse la plus montrée du doigt a été la vitesse.
Sur ce point, Rico Mariani, un des membres les plus influents de l'équipe de développeurs, confie sur son blog que le multi-threading a été au centre de ses préoccupations :
…the product is a lot more multi-threaded than previous versions and in some cases synchronization between threads was less than great.
Pour lui, le problème de la vitesse n'est encore que partiellement réglé, notamment au moment du lancement des logiciels.
Néanmoins, Visual Studio 2010 resterait pour l'instant plus lent que sa mouture précédente de 2008.
Il s'en explique :
We've managed to trip around 30% of the startup time since Beta 1 but we still are slower than Visual Studio 2008. Part of the reason is that we are now bootstrapping the CLR which is causing an increase in the time. We're looking to further improve this number but it's unlikely we'll get to VS 2008 levels.
Rico Mariani avoue d'ailleurs être déjà au travaille.
Il détaille ces futurs travaux dans un billet très complet où il fait le bilan de l'avancement du projet :
Memory is of course the main issue and there are three main sources of bad consumption that are getting targeted:
1. Managed images, especially ngen’d images. It’s just super, super, simple to take a dependency on a whole DLL in the managed world when all you need is a tiny slice of it. This has the lovely property that others then build on those DLLs creating a great big tree of unneededness. The good news is that examination can often lead to good refactoring opportunities which can save everyone a lot of memory. This is for sure the #1 issue.
2. Unshared, unmanaged Heaps. There are many low level pieces that manage their own memory and they inevitably do it with CreateHeap – joy. Of course they make their own nice giant heap ready to go and then put about 22 bytes in it. Multiply that by all the components that think they need their own private heap and it gets unpleasant awfully quick. Thankfully, this, too, is somewhat addressable. Interestingly managed memory use hasn't been a big problem other than it's fair share of leaks (see next)
3. Memory leaks, pretty much universally, can be a problem in a product the size of VS. No technology is immune but I sure like finding the managed ones better than the unmanaged – they literally can’t hide. Other things that look like leaks but aren’t really – it’s important to use AddMemoryPressure/RemoveMemoryPressure to give the GC a chance to help you with your handle objects. VS has a lot of those.
1. Managed images, especially ngen’d images. It’s just super, super, simple to take a dependency on a whole DLL in the managed world when all you need is a tiny slice of it. This has the lovely property that others then build on those DLLs creating a great big tree of unneededness. The good news is that examination can often lead to good refactoring opportunities which can save everyone a lot of memory. This is for sure the #1 issue.
2. Unshared, unmanaged Heaps. There are many low level pieces that manage their own memory and they inevitably do it with CreateHeap – joy. Of course they make their own nice giant heap ready to go and then put about 22 bytes in it. Multiply that by all the components that think they need their own private heap and it gets unpleasant awfully quick. Thankfully, this, too, is somewhat addressable. Interestingly managed memory use hasn't been a big problem other than it's fair share of leaks (see next)
3. Memory leaks, pretty much universally, can be a problem in a product the size of VS. No technology is immune but I sure like finding the managed ones better than the unmanaged – they literally can’t hide. Other things that look like leaks but aren’t really – it’s important to use AddMemoryPressure/RemoveMemoryPressure to give the GC a chance to help you with your handle objects. VS has a lot of those.
Mais est-il bon ?
Source :
Lire aussi :
Et vous :
-
la premiere beta ne gerait pas les dépendances entre projet sur les projets C++ (par exemple, un exe dépend d'un projet dll et est sensé lier avec, bah c'etait pas géré).
Il semble qu'ils aient encore fait un enorme effort sur le CLR et sur C#, mais que le code natif passe un peu a la trappe niveau fonctionnalités.
C'est inquietant pour nous qui avons un GROS projet C++ natif; j'ai peur que le Intellisense sur le C++ natif soit encore plus lent, et que le build ne soit pas facilité.le 25/08/2009 à 14:52 -
jkakimMembre habituéSalut,
Depuis la version 2005 de Visual Studio, nous avons assisté à un outil de dev assez innovant : intellicense, réflexion, contrôleur d'erreurs, déboggeur, et plus ... en 2008 c'était encore renforcé, personnellement VS est le seul IDE qui puisse me donner autant de goût lorsque je tape le CODE, j'adore.
la version 2010 nous ne pouvons que le prendre avec beaucoup de goût, surtout si le blème de lenteur est résolu.
Mais le seul truc que nous reprochons à VS est la quantité d'espace qu'il occupe en disque dur, le manque de la fonctionnalité de management de projet et ses manière de mettre à jour les projets conçu dans une version anterieurs, c'est cassant !le 25/08/2009 à 15:29 -
smyleyExpert éminentle 25/08/2009 à 16:53
-
nutsy2005Membre du ClubOn va pouvoir tester Delphi 2010 vs Visual Studio 2010
Cela pourrait être intéressant !le 26/08/2009 à 0:43 -
unmanosMembre habituéComme l'a dit screetch, je suis aussi inquiet du manque de support/ajout de fonctionnalités pour le C++. Certes on peut dire que le compilateur fonctionne très bien, mais pour intellisense, des qu'il s'agit du C++, c'est vraiment random, si on a de la chance ça marche... et quand ça marche vraiment plus trop, il faut deleter le NCB a la main et espérer qu'il s'y retrouve mieux... franchement c'est pas sérieux, et ça fait presque 10 ans que ça dure.
Si Doxygen arrive à extraire toutes les symboles d'un projet C++ correctement (y compris les templates un peu tordu), pourquoi MS n'y arriverait pas?
Enfin si ca pouvait marcher au moins comme VC2008 pour le C++, je me plaindrais pas
Pour la CLR, c'est tout simplement génial, "I love WPF" pour les tools!le 26/08/2009 à 9:13 -
BakuraRédacteurTu as essayé la bêta du 10 ? Ok, elle est lente, mais s'il y a bien quelque chose qui a évolué, c'est bien Intellisense ! Autant sur 2005 et 2008 (même si il y a eu du progrès) ça marchait un peu quand ça voulait, autant sous le 2010 je n'ai eu aucun problème et ça a toujours fonctionné, que ce soit avec du C++ natif ou des bibliothèques externes.Comme l'a dit screetch, je suis aussi inquiet du manque de support/ajout de fonctionnalités pour le C++. Certes on peut dire que le compilateur fonctionne très bien, mais pour intellisense, des qu'il s'agit du C++, c'est vraiment random, si on a de la chance ça marche... et quand ça marche vraiment plus trop, il faut deleter le NCB a la main et espérer qu'il s'y retrouve mieux... franchement c'est pas sérieux, et ça fait presque 10 ans que ça dure.
Et la détection de certaines erreurs en temps réel sans recompiler est vraiment un gros gros plus qui fait économiser énormément de temps.le 27/08/2009 à 12:35 -
unmanosMembre habituéJ'ai essaye avec des projet C#, sans penser que MS avait pu améliorer (meme juste toucher) le dev en C++, voila une très bonne nouvelle.le 30/08/2009 à 8:21
-
intellisense chez nous bouffe toujours 12,5% du CPU (un core entier sur ma machine) et n'arrive pas encore a tout trouver, ca n'a pas complètement marché sur notre projetle 30/08/2009 à 10:19