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 :
![:fleche:](https://www.developpez.net/forums/images/smilies/fleche.gif)
![:fleche:](https://www.developpez.net/forums/images/smilies/fleche.gif)
Lire aussi :
![:fleche:](https://www.developpez.net/forums/images/smilies/fleche.gif)
![:fleche:](https://www.developpez.net/forums/images/smilies/fleche.gif)
Et vous :
![:fleche:](https://www.developpez.net/forums/images/smilies/fleche.gif)