Aurelio è uno dei tanti fruitori di Radical (che vi ricordo ha cambiato casa) e mi ha segnalato un fastidioso problema di performance nel momento in cui viene messa in binding una list di entità, basate sulla classe base “AbstractViewModel” di Radical, la cui numerosità sia corposa:

Nell’esempio, che Aurelio ha prodotto per riprodurre il problema, a sinistra vengono create 2.000 istanze di un banalissimo ViewModel che implementa direttamente INotifyPropertyChanged, mentre a destra viene fatta la stessa cosa con un ViewModel che eredita da “AbstractViewModel”. Come si nota i tempi sono abissalmente superiori e anche inaccettabili direi; c’è da dire che AbstractViewModel, e tutta l’infrastruttura che c’è dietro fanno di gran lunga più cose di quello che banalmente fa INotifyPropertyChanged, quindi una differenza di prestazioni è ovviamente attesa.

Sinceramente non mi ero mai posto neanche il problema di caricare 2.000 elementi in una lista visualizzata su una UI, ma è ovvio che i miei use case non sono quelli del resto del mondo, mi sono quindi armato di profiler (un buon dotTrace non si nega a nessuno) e ho fatto qualche aggiustamento qua e la:

Non male direi, con 2.000 elementi adesso vinco io :-)

La cosa diventa interessante se proviamo a spingere un po’ sull’acceleratore:

proviamo a caricare 20.000 elementi e nonostante il framework ritorni a vincere a mani bassi Radical si difende comunque molto bene.

.m