1. Accueil
  2. Question et réponse
  3. Une raison pour laquelle NGEN devrait se bloquer et ne jamais se terminer pour un assemblage particulier?

Une raison pour laquelle NGEN devrait se bloquer et ne jamais se terminer pour un assemblage particulier?

2010-04-15 6 views
2

J'ai un projet de bibliothèque de classe pour .NET 3.5 construit avec Visual Studio 2008.Une raison pour laquelle NGEN devrait se bloquer et ne jamais se terminer pour un assemblage particulier?

Si j'essaie de NGEN l'ensemble de base dans ce fichier de solution, NGEN ne se termine jamais, ou du moins pas dans le temps que j'ai dérangé pour le laisser fonctionner (comme une nuit).

Quelqu'un d'autre a-t-il déjà vécu cela? Et si oui, l'avez-vous résolu? Et si tu l'as fait, comment? Quelles étapes avez-vous suivies?

S'il s'agit d'un bogue dans NGEN, comment puis-je l'envoyer à Microsoft? J'ai un compte de connexion, mais où puis-je poster un rapport de bogue pour ce produit particulier, au lieu d'une classe .NET (que je sais où aller.)

La bibliothèque de classes en question peut être trouvée ici:

l'ensemble est problématique l'ensemble LVK.Core.

Mise à jour: NGEN pour .NET 4.0 terminée, mais il a fallu près de 15 minutes pour le faire:

time /t 
12:44:39 
ngen install lvk.core.dll 
Microsoft (R) CLR Native Image Generator - Version 4.0.30319.1 
Copyright (c) Microsoft Corporation. All rights reserved. 
Installing assembly C:\Dev\VS.NET\LVK\LVK.Core\bin\x86\Debug\lvk.core.dll 
    Compiling assembly C:\Dev\VS.NET\LVK\LVK.Core\bin\x86\Debug\lvk.core.dll (CLR v2.0.50727) ... 
LVK.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=8dbb1dd9b1276c0a <debug> 
time /t 
12:59:24

Mise à jour # 2: question Créé en Microsoft Connect.

Source

2010-04-15 Lasse Vågsæther Karlsen

Répondre

2

La raison pour cela a été trouvée plus tard être ma mise en œuvre de classes génériques Tuple<...>.

Il se trouve que le processus JIT lorsqu'il est invoqué par NGEN va créer des versions NGEN'ed de chaque type Tuple<...> pour les types suivants:

  1. Une version commune pour tous les types de référence
  2. Une version pour chaque Type

Depuis que j'avais tuple versions jusqu'à 16 arguments génériques, pour faire bonne mesure, NGEN était occupé barattage toutes les combinaisons il y avait un Tuple<T1, T2, T3, T4, ..., T16> pour tous les types de valeur.

J'ai réduit le nombre de types à moins d'arguments génériques, et NGEN est maintenant terminé.

Source

2010-11-08 08:29:39

+0

Cas intéressant; alors ... le code source a-t-il utilisé beaucoup de permutations différentes de 'T'? On peut supposer que NGEN n'inventait pas * des permutations? –

+0

C'est exactement ce que ça fait. Il génère des combinaisons JITted pour tous les types de valeur * dans cet assembly *, * toutes les combinaisons *, "juste au cas" (je suppose que c'est une variation différente de Just-in-time). La bibliothèque est une bibliothèque de classes, pour la plupart de ces types il n'y avait aucune utilisation, juste la définition de classe. Je suis cependant allé trop loin avec la définition, puisque je l'ai générée avec un script python, donc je n'ai vu aucun mal à simplement "planifier pour le futur". Je suppose que j'étais bien sur mon chemin vers la lune en tant qu'architecte à l'époque :) –

Questions connexes

 Questions connexes