Questo blog-entry é stato ricavato da una mail interna in cui spiegavo a dei colleghi di CA che stanno lavorando su Silverlight 4.0 come ho risolto un antipatico problema di prestazioni ed uso eccessivo del processore di una applicazione Silverlight 4.0. Ve la riporto pari pari Cool

.... Ciao, avete presente la shell silverlight sulla quale stiamo lavorando ? beh uno dei problemi era quello delle prestazioni e dello “strano” utilizzo elevato del processore anche quando non si faceva nulla. Dopo aver un po’ cercato su internet mi sono immediatamente imbattuto in due articoli che spiegano come abilitare il profiling per applicazioni Silverlight, cosa non supportata ufficialmente o “out of the box” apparentemente con vs2010. Oltre a leggere gli articoli ho dovuto smanettare veramente poco a causa del mio sistema a 64 bit.

Quindi ... grazie a questo articolo:

http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx

e questo per preparare il browser internet opportunamente per la gestione dei processi

http://blogs.msdn.com/mgoldin/archive/2010/04/26/vs2010-silverlight-4-profiling.aspx

ho beccato dopo una sessione di profile questo giro nell’applicazione aprendo il file di profiling direttamente dentro vs2010 con Open File (doppio click da shell/explorer non funziona):

”

 

Osservate cosa fa vstudio 2010 se cliccate sul link di cui sopra:

Apre il sorgente e aggiunge una carinissima icona che mostra il punto incriminato con un bel fuocherello:

 


L’istruzione di sincronizzazione della sezione critica é assolutamente incolpevole. Seguendo il call-stack scopro che la colpa é di chi la chiama in modo esagerato da un ciclo for-ever, causa reale del problema. Con un piccolo walk dello stack e grazie al profiler e le sue indicazioni sono arrivato nella funzione di cui sotto. Sostanzialmente la sleep per fare un po’ di “yielding” (termine inadatto: non é multiprogrammazione peró fa respirare gli altri processi lo stesso) é nel posto sbagliato !!!!!

... Commentandola (in rosso) e spostandola fuori dal blocco THEN (in giallo) dell’IF il problema é risolto in un attimo e l’applicazione passa dal 25% (sul mio quad-core !!!!) a 0% a beneficio delle animazioni ecc.

     /// <summary>
      /// Occurs when worker is runned.
      /// </summary>
      /// <param name="sender"></param>
      /// <param name="Argument"></param>

      protected override void OnRun(AsyncWorker<object> sender, object Argument)
      {
         base.OnRun(sender, Argument);
         bool terminationCondition = false;

         lock (this.SyncForceTermination)
         {
            terminationCondition = this.ForceTermination;
         }

         while ( ! terminationCondition )
         {
            TTask task = default(TTask);
            lock (this.SyncTasks)
            {
               if (this.Taks.Count > 0)
               {
                  task = this.Taks.Dequeue();
               }
            }

            if (task != null)
            {
               TTaskManagerJob job = default(TTaskManagerJob);
               if (task.TaskType == TaskType.None)
               {
                  job = BuildJobContext(new Object[] { task });
               }
               else
               {
                  job = (TTaskManagerJob)BuildJobContext(this.GetTaskType(task), new Object[] { task });
               }

               job.OnTermination -= new EventHandler<WorkerJobEventArgs<TTask>>(Job_OnTermination);
               job.OnTermination += new EventHandler<WorkerJobEventArgs<TTask>>(Job_OnTermination);

               ThreadPool.QueueUserWorkItem(job.Execute);

               // Thread.Sleep(100); // =DG= rimosso per performance

               lock (this.SyncForceTermination)
               {
                  terminationCondition = this.ForceTermination;
               }

            }

            Thread.Sleep(100); // =DG= aggiunto per performance

         }

      }

Giuseppe