Que se passe-t-il entre l'appel de méthode et l'entrée de méthode (C#)?

Question

En ce moment, nous avons un problème avec le démarrage d'une application WPF de taille moyenne. Il faut environ 15 secondes pour charger complètement. Nous nous sommes demandés ce qu'il fallait si longtemps.

Dans l'événement Application_Startup of App.xaml, un automate est initialisé. Ce contrôleur réside dans un assembly 'business' distinct, qui appelle à son tour l'assembly 'data' pour collecter des informations sur l'utilisateur et ainsi de suite. Ces assemblages sont relativement petits, 160k et 60k.

Le temps nécessaire pour participer à cet événement était de 15 secondes. Nous avons donc séparé le code dans une autre méthode et l'appelons dans l'événement. Avec cette modification, nous avons trouvé le débogueur entrer l'événement Application_Startup directement après le démarrage. Cependant, à partir du moment où il atteint la ligne qui appelle la méthode séparée et entre dans cette méthode, il a fallu 15 secondes.

Pendant cette période, rien ne s'est passé dans la fenêtre de sortie ou de callstack de Visual Studio. Donc, les questions sont:

1. Y at-il un moyen de voir ce qui se passe après un appel de méthode et avant d'entrer dans la méthode?
2. Les assemblages sont-ils nécessaires dans une méthode de chargement dans cette période de 15 secondes? Si c'est vrai, quelles sont les façons de raccourcir ce temps?

Merci d'avance pour les réponses.

modifier, le code demandé de la méthode séparée:

 try 
     { 
      // Check whether debug mode is enabled or not. 
      string[] commandArgs = Environment.GetCommandLineArgs(); 
      ApplicationLog.DebugMode = 
       (commandArgs.Length > 1 && 
       (commandArgs[1].IndexOf("debug") > 0) || 
       (commandArgs.Length > 2 && commandArgs[2].IndexOf("debug") > 0)); 

      // Logging startup. 
      ApplicationLog.Log("Starting at " + Environment.MachineName, 21003); 

      // Check to start configtool or main application. 
      if (commandArgs.Length > 1 && 
       (commandArgs[1].IndexOf("config") > 0 || commandArgs[2].IndexOf("config") > 0)) 
      { 
       ConnectionStringWindow window = new ConnectionStringWindow(); 
       window.DataContext = new ViewModels.ConnectionStringViewModel(); 
       window.Show(); 
      } 
      else 
      { 
       // The main window. 
       MainWindow mainWindow = new MainWindow(); 
       mainWindow.Closing += mainWindow_Closing; 

       // New ViewModel. 
       mainWindow.DataContext = new ViewModels.MainWindowViewModel(mainWindow); 

       // Display. 
       mainWindow.Show(); 
      } 
     } 
     catch (Exception ex) 
     { 
      ApplicationLog.Log(ex, 22001); 

      if (ApplicationLog.DebugMode) 
      { 
       Microsoft.SqlServer.MessageBox.ExceptionMessageBox box = new Microsoft.SqlServer.MessageBox.ExceptionMessageBox(
        ex.Message, 
        "Application", 
        Microsoft.SqlServer.MessageBox.ExceptionMessageBoxButtons.OK, 
        Microsoft.SqlServer.MessageBox.ExceptionMessageBoxSymbol.Error); 
       box.InnerException = ex; 
       box.ShowCheckBox = false; 

       box.Show(null); 
      } 
      else 
      { 
       MessageBox.Show(ex.Message, "Application", MessageBoxButton.OK, MessageBoxImage.Error); 
      } 

      // Close application. 
      Application.Current.Shutdown(); 
     } 

Answer 1

Vous pouvez utiliser Process Monitor outil pour voir ce qui se passe dans les coulisses. Au moins, vous pouvez voir quels fichiers (par exemple les assemblys .NET) sont lus, quels répertoires sont analysés, etc. Vous pouvez également décocher la case 'Juste mon code' dans les options du débogueur VS et cocher 'Activer l'option de progression de la source .NET Framework' au même endroit. Cela produira au moins une trace de pile plus détaillée. Si rien ne vous permet d'utiliser WinDbg pour parcourir le code géré et non géré.