December 2005 - Posts
Ho pubblicato sul blog DevLeap questo post per proporvi un mio workaround a una serie di limitazioni a Visual Studio Team System rispetto a soluzioni mobile. Non è una critica al prodotto, anzi, lo ritengo uno dei più bei strumenti di sviluppo ad oggi in circolazione; vuole essere semplicemente una strada da valutare per sfruttare al massimo VS 2005 Team System che ha un po' di limitazioni nei designer e sugli strumenti Developer e Tester rispetto ai progetti mobile.
Buona lettura: http://blogs.devleap.com/rob/archive/2005/12/29/6428.aspx
Sperando che i device mobili non vi costringano a stare online anche quando siete in ferie...buone feste a tutti :-)
RoB
Ecco pubblicate anche slide e demo di Marco. Ripropongo tutti i link per uniformità: New accanto alle novità rispetto al post precedente
Ho appena pubblicato slide e demo (per adesso di Fabio e mie) della conferenza in oggetto:
Plenaria
Demo Client Windows che visualizza foto uploadate tramite il client mobile ftp://thinkmobile.it/MMDCII/PlenariaDemoRob.zip
Demo Client Mobile che invia foto via Web Service al client Windows: ftp://thinkmobile.it/MMDCII/PlenariaMobileClient_SpeakerDemo.zip
Sessione 1: Intro to .NET CF
Slide Marco: ftp://thinkmobile.it/MMDCII/1_IntroMobileAndCFMarco.zip (New)
Sessione 2: .NET CF 2.0, VS 2005, Generics, Anonoymous Method, MultiThread, Invoke/BeginInvoke
Slide Rob: ftp://thinkmobile.it/MMDCII/2_MultiThreading20SlideRob.zip
Demo Client Mobile con Binding verso Collection (Generics) Fabio ftp://thinkmobile.it/MMDCII/2_EnergiaDemoFabio.zip
Demo Client Mobile Multithread Rob (esempio completo di cui è stato mostrato solo la parte .NET CF 2.0, Generics, BeginInvoke, Anonymous Method): ftp://thinkmobile.it/MMDCII/2_MultiThread_10_20DemoRob.zip
Sessione 3: Scambio Informazioni
Slide: ftp://thinkmobile.it/MMDCII/3_ScambioInformazioniSlideRob.zip
Demo MSMQ ftp://thinkmobile.it/MMDCII/3_MSMQDemoRob.zip
N.B. Questo zip contiene un progetto di esempio che usa un helper per MSMQ "locale" ai fini demo. Un helper per MSMQ è incluso nello zip in fondo al post
Sessione 4: SQL Server 2005 Mobile Edition (aka Sql Mobile)
Slide Rob: ftp://thinkmobile.it/MMDCII/4_SQL2005MobileSlideRob.zip
Demo SDF, VS2005, SQL Server ftp://thinkmobile.it/MMDCII/4_DataDemoFabio.zip
Demo SQL 2005 Mobile Performance (compreso Test.xls): ftp://thinkmobile.it/MMDCII/4_SQL2005MobilePerformanceDemoRob.zip
N.B. Usa l'helper per SQL 2005 Mobile incluso in DevLeap.System.Mobile (zip allegato in fondo al post)
Slide Marco su RDA e Merge Replication: ftp://thinkmobile.it/MMDCII/4_SQLServerCESlideMarco.zip (New)
Demo Marco su RDA e Merge Replication: ftp://thinkmobile.it/MMDCII/4_SQLServerCEDemoMarco.zip (New)
Sessione 5: Connettività (New)
Slide Marco: ftp://thinkmobile.it/MMDCII/5_ConnettivitàSlideMarco.zip (New)
Demo Marco: ftp://thinkmobile.it/MMDCII/5_ConnettivitàDemoMarco.zip (New)
Sessione 6: Sessione Tips & Tricks
Slide Rob: ftp://thinkmobile.it/MMDCII/6_TipsAndTricksSlideRob.zip
N.B. Le funzioni usate sono in DevLeap.System.Mobile (zip allegato in fondo al post)
Slide Marco: ftp://thinkmobile.it/MMDCII/6_TipsAndTricksSlideMarco.zip (New)
Demo Marco: ftp://thinkmobile.it/MMDCII/6_TipsAndTricksDemoMarco.zip (New)
Helper SQL 2005 Mobile, Utility, Helper MSMQ (DevLeap.System.Mobile)
Componenti riutilizzabili per Helper SQL 2005 Mobile, Helper MSMQ, Utility (App.Path, Lettura Config, GetIP).
N.B. Questi componenti sono forniti in formato sorgente: non sono completi e non prevedono tutte le casistiche; il sorgente viene fornito come spunti per crearsi i propri componenti helper per SQLCE, SQL 2005 Mobile, MSMQ per Windows CE e Utility varie. Lo zip contiene 3 progetti distinti da aggiungere alle proprie Solution oppure da compilare stand-alone e usare come reference dai progetti.
ftp://thinkmobile.it/MMDCII/DevLeap.System.Mobile.zip
Su segnalazione di Gustavo vi informo che il file delle slide della seconda sessione è corrotto. Oggi a pranzo appena torno in ufficio lo ricreo. Scusate per l'inconveniente.
Per abilitare la creazione delle statistiche del .NET Compact Framework la chiave (da creare se non c'è) è sotto HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\PerfMonitor.
Occorre creare un value di tipo DWORD chiamata Counters e impostare il valore a 1. Chiave assente o con valore 0 disabilita il collezionamento dei dati.
Nel .NET CF 1.0 viene creato un file mscoree.stat per tutte le applicazioni. Nella 2.0 un file per ogni applicazione.
In entrambi i casi il file viene creato all'uscita dell'applicazione.
Ho appena pubblicato slide e demo (per adesso di Fabio e mie) della conferenza in oggetto:
Plenaria
Demo Client Windows che visualizza foto uploadate tramite il client mobile ftp://thinkmobile.it/MMDCII/PlenariaDemoRob.zip
Demo Client Mobile che invia foto via Web Service al client Windows: ftp://thinkmobile.it/MMDCII/PlenariaMobileClient_SpeakerDemo.zip
Sessione 2: .NET CF 2.0, VS 2005, Generics, Anonoymous Method, MultiThread, Invoke/BeginInvoke
Slide Rob:
Demo Client Mobile con Binding verso Collection (Generics) Fabio ftp://thinkmobile.it/MMDCII/2_EnergiaDemoFabio.zip
Demo Client Mobile Multithread Rob (esempio completo di cui è stato mostrato solo la parte .NET CF 2.0, Generics, BeginInvoke, Anonymous Method): ftp://thinkmobile.it/MMDCII/2_MultiThreading20SlideRob.zip
Sessione 3: Scambio Informazioni
Slide: ftp://thinkmobile.it/MMDCII/3_ScambioInformazioniSlideRob.zip
Demo MSMQ ftp://thinkmobile.it/MMDCII/3_MSMQDemoRob.zip
N.B. Questo zip contiene un progetto di esempio che usa un helper per MSMQ "locale" ai fini demo. Un helper per MSMQ è incluso nello zip in fondo al post
Sessione 4: SQL Server 2005 Mobile Edition (aka Sql Mobile)
Slide Rob: ftp://thinkmobile.it/MMDCII/4_SQL2005MobileSlideRob.zip
Demo SDF, VS2005, SQL Server ftp://thinkmobile.it/MMDCII/4_DataDemoFabio.zip
Demo SQL 2005 Mobile Performance (compreso Test.xls): ftp://thinkmobile.it/MMDCII/4_SQL2005MobilePerformanceDemoRob.zip
N.B. Usa l'helper per SQL 2005 Mobile incluso in DevLeap.System.Mobile (zip allegato in fondo al post)
Sessione 6: Sessione Tips & Tricks
Slide Rob: ftp://thinkmobile.it/MMDCII/6_TipsAndTricksSlideRob.zip
N.B. Le funzioni usate sono in DevLeap.System.Mobile (zip allegato in fondo al post)
Helper SQL 2005 Mobile, Utility, Helper MSMQ (DevLeap.System.Mobile)
Componenti riutilizzabili per Helper SQL 2005 Mobile, Helper MSMQ, Utility (App.Path, Lettura Config, GetIP).
N.B. Questi componenti sono forniti in formato sorgente: non sono completi e non prevedono tutte le casistiche; il sorgente viene fornito come spunti per crearsi i propri componenti helper per SQLCE, SQL 2005 Mobile, MSMQ per Windows CE e Utility varie. Lo zip contiene 3 progetti distinti da aggiungere alle proprie Solution oppure da compilare stand-alone e usare come reference dai progetti.
ftp://thinkmobile.it/MMDCII/DevLeap.System.Mobile.zip
Appena arrivano le slide e le demo di Marco farò un altro post.
Mi raccomando: scrivete SEMPRE su Layer diversi (UI, BIZ, DAL, DAL Helper) !!!! :-)
Come da post ufficiale del team del .NET CF (http://blogs.msdn.com/netcfteam/archive/2005/11/28/497759.aspx), Windows CE 4.2 non è una piattaforma supportata dalla nuova versione del .NET Compact Framework. Nel primo semestr 2006 dovrebbe però uscire un Service Pack per .NET CF 2.0 che consente l'installazione anche su questo S.O. molto diffuso sui device industriali. Con il SP sarà possibile installare anche SQL 2005 Mobile Edition.
Lo SmartPhone 2003 non supporta .NET CF 2.0 in quanto la directory windows (dove il .NET CF si installa) non viene persistita: questo significa che non è possibile sovrascrivere i file del .NET CF che stanno in ROM. Questo è il motivo per cui lo SP 2003 non supporta .NET CF 2.0. In effetti anche per il .NET CF 1.0 è impossibile installare i vari SP.
Uno schemino per aiutare nella scelta di un device industriale con Windows CE 5.0 che esiste in versione Core Pro e Pro Plus. Ad esempio l'MC 3090 di Symbol può essere acquistato in versione Core o Plus.
Windows CE 5.0 Core |
- Non include ActiveSync (Inbox Syuc and Pocket Outlook Database Sync) AV Renderer sample AYGShell LAP and Configuration utility Bluetooth LAP and Configuration utility File Server (10 connection limit) Help Microsoft Internet Explorer (full browser and Pocket Internet Explorer) Inbox Microsoft file viewers Pocket Outlook Object Model API RAS/PPTP Server Remote Desktop Protocol (RDP) Speech Reconition engine Standard SDK for Windows CE (AYG) Streaming Media Playback Transcriber Handwriting Recognition engine and application Microsoft Windows Messenger Microsoft Windows Media Player application Windows Thin Client shell WMA, WMV and MP3 streaming (by using Windows Media Player) Microsoft WordPad - Target Devices: Gateways, Entry-level Voice-over-IP (VoIP) phones, Industrial Automation Equipment, and Consumer Electronic Devices (such as CD Players, Digital Cameras, and Networked DVD Players) |
| Windows CE 5.0 Professional |
- Provides Windows Messengers, WordPad, Remote Desktop Protocol(RDP), Internet Explorer 6.0 ,etc. |
| Windows CE 5.0 Professional Plus |
- Provides File Viewer (MS Office document, Adobe Acrobat, Image files, etc.) |
Questo componente http://www.microsoft.com/downloads/details.aspx?FamilyID=cdfd2bb2-fa13-4062-b8d1-4406ccddb5fd&DisplayLang=en denominato Redistributable Server Component for Windows Mobile 5.0 che contiene quanto è stato escluso dagli SDK per la versione 5.0 di Windows Mobile. Contiene:
MSMQ: Librerie, Visadm.exe e msmqadm.exe per l'installazione e l'amministrazione di MSMQ lato Device
HTTPD: Ormai famoso Web Server per Windows CE
PeerNet: Servizi Peer-to-Peer (core library, Peer Name Resolution Protocol (PNRP) Namespace Provider (NSP)
UPnPCtrl: UPnP control library
UPnPHost: Device library per UPnP
Nelle versioni 4.2 degli SDK MSMQ e HTTPD erano inclusi nel pacchetto, mentre in questa versione sono stati separati in questo componente grauito aggiuntivo.
Tutti i componenti si scompattano al volo sul desktop senza richiesta di path di installazione. Sono tutti CAB per il processore ARM (anche gli emulatori installati con VS 2005 o con il Device Emulation Manager sono basati su processore ARM).
Peccato solo che i cab non sia firmati e con il nuovo modello di security di Windows Mobile possano dare problemi di installazione: sui device in prompt-mode verrà chiesta la conferma per scompattare e installare il tutto; fastidiosa, ma comunque è una operazione da eseguire una sola volta. Sui device "chiusi" sarà un problema installare il tutto dal cab :-(
La documentazione non viene installata ma è accessibile all'indirizzo http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/mob5oriOptionalServerComponents.asp?frame=true
http://www.microsoft.com/downloads/details.aspx?FamilyID=dc8332d6-565f-4a57-be8c-1d4718d3af65&displaylang=en
E' un driver di rete virtuale per l'emulatore Pocket PC o Smartphone. Consente al sistema operativo dell'emulatore (o volendo di un macchina ospitata in Virtual PC) di emulare una connessione di rete: la rete fisica sulla macchina host viene virtualizzata e di conseguenza è possibile associare un IP al Device Emulator. L'emulatore può connettersi via TCP o UDP senza nessun bisogno di legarsi al PC tramite ActiveSync.
Domani parto per Catania per tenere una conferenza all'Università per conto di Microsoft Italia. La mattina parleremo di Mobility, mentre il pomeriggio di Team System. Se avrò il permesso pubblicherò le slide sul sito.
Iniziano a uscire i device industriali con Windows CE 5.0. http://www.symbol.com/MC3000/.
Hanno fatto un bel salto in avanti come RAM/ROM e processori. Lo schermo per entrambi i modelli sarà 320x320 Square.
Interessante: entrambi i modelli montano schede wireless anche 802.11g a 54 Mbps
Segnalazione dell'amico Aldo: http://www.repubblica.it/2005/k/sezioni/scienza_e_tecnologia/cellumusi/supercellu/supercellu.html
Da paura....aspettiamo di vedere i costi....:-)
Sono in un hotel a Genova: la connettività wireless in camera...che in USA è al 99% gratuita....costa 40 Euri al giorno....la camera costa 80 giusto per fare un paragone :-)
Ho terminato la serie di test che mi ero prefisso. In questa prima parte analizziamo i risultati di una query di inserimento massiccio record utilizzando un comando di INSERT su una tabella semplice così composta:

La tabella ha 3 indici: il primo (PK) sul campo IdArticolo e gli altri due sui campi descrizione e prezzo.

La tabella è molto semplice (penso sia una delle classiche tabelle articolo anche se opportunamente ridotta come numero di campi) anche se consente di esegue successive ricerche o ordinamenti indicizzati per Prezzo e Descrizione.
Una tabella così semplice non dovrebbe aver nessun tipo di problemi di performance, a prescindere dal metodo di utilizzo. Vedremo in questa parte l'inserimento di record e nelle parti successive la SELECT di tutti i record, la SELECT di un range di record e la SELECT di un singolo record con diverse tecniche.
Metodo tradizionale e spesso consigliato (purtroppo) sulla letteratura informatica mobile:
for (long i = 0; i < quanti; i++)
{
SqlCeParameter paramIdArticolo = new SqlCeParameter("@IdArticolo", SqlDbType.NChar, 10);
SqlCeParameter paramArticoloDex = new SqlCeParameter("@ArticoloDex", SqlDbType.NVarChar, 100);
SqlCeParameter paramArticoloPrezzo = new SqlCeParameter("@ArticoloPrezzo", SqlDbType.Float, 18);
paramIdArticolo.Value = "Art" + i.ToString();
paramArticoloDex.Value = "Articolo Meraviglioso " + i.ToString();
paramArticoloPrezzo.Value = i;
SqlHelper.ExecSPNonQuery(Utility.GetConnectionStringLocal("SQL2005MobilePerformance.config"),
"INSERT INTO tabArticoli (IdArticolo, ArticoloDex, ArticoloPrezzo) VALUES (@IdArticolo, @ArticoloDex, @ArticoloPrezzo)",
new SqlCeParameter[] { paramIdArticolo, paramArticoloDex, paramArticoloPrezzo });
}
Le tempistiche di questo test sono state calcolate con Environment.TickCount che resituisce il numero di millisecondi da quanto il device è stato avviato: non è una misurazione perfetta, ma per analizzare tempi "lunghi" va benissimo. Una sola nota: se il device è acceso da troppo tempo questo valore diventa negativo, sballando completamente le statistiche: per questo motivo i test sono stati effettuati resettando il device; inoltre TickCount utilizza la funzione Win32 GetTickCount che non è accuratissima per operazioni brevi in quanto introduce una varianza fino a 500 ms. Nei test successivi ho utilizzato una funzione che poi pubblicherò sul blog che calcola in base a QueryPerformanceCounter e QueryPerformanceFrequency un valore molto più accurato.
Quando si eseguono test è necessario ripetere l'operazione almeno una seconda volta in quanto alla prima esecuzione il JIT Compiler compila al volo i metodi da eseguire; inoltre, se l'exe carica dll (come nel nostro caso la SqlHelper per eseguire comandi fisici sul db) di conseguenza il valore "buono" da considerare arriva alla seconda esecuzione. In realtà, per un test accurato occorre eseguire più volte il codice e prendere come risultato valido la media dei valori.
Il test è stato eseguito 10 volte, scartando il primo valore per calcolare la media e i risultato riportano sia la media, sia il valore migliore, sia il risultato di ogni iterazione.
Risultati del test di inserimento con il codice precedente (tempi in millisecondi):
| Fill DB (100 Record) |
Media(2-10) |
Best |
Test1 |
Test2 |
Test3 |
Test4 |
Test5 |
Test6 |
Test7 |
Test8 |
Test9 |
Test10 |
| Normale |
47784.22 |
45780.00 |
52000 |
47000 |
46980 |
48980 |
46788 |
46890 |
45780 |
49990 |
47890 |
49760 |
In soldoni l'inserimento di 100 record impiega 47,78 secondi di media per essere eseguito...un'enormità !
Il problema nel codice precedente sta nel fatto che l'helper di accesso ai dati, comodissimo per evitare tutti i dettagli di creazione comando, connessione, parametri, apre la connessione per ogni inserimento, definisce un oggetto SqlCeCommand, associa i parameteri e infine esegue il comando. Nell'ambiente Windows CE l'utilizzo del database è profondamente diverso rispetto a quanto siamo abituati a fare con SQL Server o Oracle nell'ambiente DeskTop o Server. Come regola generale, ad esempio, non esiste il connection pooling: eseguendo poche open/close e soprattutto riutilizzando lo stesso SqlCeCommand, per eseguire le query più utilizzate, si risparmia un sacco di tempo (dove "un sacco di tempo" vuol dire quello che vedremo con il risultato del test seguente). In questo caso, visto che facciamo un bulk insert anche sull'ambiente desktop/server converrebbe aprire una sola volta la connection, eseguire il lavoro, chiudere la connection.
Il codice seguente crea un SqlCeCommand con parametri per poi il ciclo di insert. Si utilizza un comando Prepared per indicare a ADO.NET che vogliamo eseguire il comando spesso e quindi cachare il piano di esecuzione della query:
SqlCeParameter paramIdArticolo = new SqlCeParameter("@IdArticolo", SqlDbType.NChar, 10);
SqlCeParameter paramArticoloDex = new SqlCeParameter("@ArticoloDex", SqlDbType.NVarChar, 100);
SqlCeParameter paramArticoloPrezzo = new SqlCeParameter("@ArticoloPrezzo", SqlDbType.Decimal, 9);
SqlCeCommand cmd = SqlHelper.PrepareCommand(Utility.GetConnectionStringLocal("SQL2005MobilePerformance.config"),
"INSERT INTO tabArticoli (IdArticolo, ArticoloDex, ArticoloPrezzo) VALUES (@IdArticolo, @ArticoloDex, @ArticoloPrezzo)",
new SqlCeParameter[] { paramIdArticolo, paramArticoloDex, paramArticoloPrezzo });
cmd.Connection.Open();
cmd.Prepare();
for (long i = 0; i < quanti; i++)
{
cmd.Parameters["@IdArticolo"].Value = "Art" + i.ToString();
cmd.Parameters["@ArticoloDex"].Value = "Articolo Meraviglioso " + i.ToString();
cmd.Parameters["@ArticoloPrezzo"].Value = i;
SqlHelper.ExecSPNonQuery(cmd, true);
}
cmd.Connection.Close();
In questo secondo caso quindi si apre la connessione, si esegue il metodo Prepare() sul comando già configurato con i parametri. Durante il ciclo valorizziamo i parametri e eseguiamo la query.
I tempi di risposta (comparati con il precedente test) ?
| Fill DB (100 Record) |
Media(2-10) |
Best |
Test1 |
Test2 |
Test3 |
Test4 |
Test5 |
Test6 |
Test7 |
Test8 |
Test9 |
Test10 |
| Normale |
47784.22 |
45780.00 |
52000 |
47000 |
46980 |
48980 |
46788 |
46890 |
45780 |
49990 |
47890 |
49760 |
| Prepared |
2453.56 |
2309.00 |
|
2500 |
2498 |
2356 |
2678 |
2399 |
2408 |
2478 |
2309 |
2456 |
Sticazzi sarebbe la parola giusta, ma su un post non è carino....accipicchia che miglioramento: si passa da 47,78 secondi a 2,4.
I valori non vanno presi in termini assoluti: non è detto che 100 record su una tabella di 3 campi con indici su tutti i campi impieghino sempre 2.4 secondi: dipende dal device, dalla velocità, da cosa sta facendo il device in quel momento: ad esempio sul mio Qtek 2020 i risultati scendono a 1,98 secondi, mentre sul JasJar con il database su scheda SD arrivano a 1,56 secondi; anche quì dipende dalla velocità di accesso della scheda. Il punto è leggere i valori in termini relativi: siamo circa 20 volte più veloci con zero sforzo nel codice. Molte volte per far andare più forte il codice occorre smanettare parecchio, e anche se personalmente preferisco scrivere sempre codice ottimizzato perchè so che nel futuro non avrò mai problemi se i record crescono o l'applicazione si complica, è anche giusto fare un rapporto costi/benefici: in questo caso costo=0 benefini=tanti.
Se per caso l'applicazione passa da 100 record a 10000 record (il DB diventa 1.42 Mb) questo il risutltato del codice:
| Fill DB (10000 Record) -> 1.42 Mb SDF |
Media(2-10) |
Best |
| Normale |
3678899.00 |
3678899.00 |
| Prepared |
188977.00 |
188977.00 |
Da 3.678 secondi a 188 secondi....vale la pena pensare due secondi al codice che stiamo scrivendo ? :-)
E ancora con 100000 record che per Sql 2005 Mobile, se il codice è scritto bene, non sono un problema !
| Fill DB (100000 Record) -> 14.1 Mb SDF |
Media(2-10) |
Best |
| Normale |
45674866.00 |
45674866.00 |
| Prepared |
1892880.00 |
1892080.00 |
Da 45.000 secondi a 1892...
Nella prossima parte pubblicherò i dati in lettura rispetto a 100, 10000, 1000000 record anticipandovi che usando una SELECT * FROM con un DataSet su 100 record si impiega 1 secondo e qualcosa, mentre con un Base Table Cursor 0,35. Anche utilizzando una propria collection tipizzata di oggetti articoli si viaggia a velocità superiore rispetto al DataSet arrivando a 0,6 secondi, ma avendo codice tipizzato, classi su cui lavorare. Tra l'altro con i Generics della versione 2.0 l'implementazione diventa molto più semplice...
Una considerazione molto importante, quando si lavora in ambiente mobile è il peso in memoria del nostro codice, il numero di oggetti allocati e il numero di volte in cui il GC è entrato in azione; ricordiamoci che ogni processo su Windows CE ha 32 Mb di spazio di indirizzamento: di conseguenza se il codice alloca troppi oggetti in memoria, il GC è costretto a eliminare i metodi JITted; alla prossima eseguzione di un metodo "scaricato dalla memoria" il JITter dovrà ricompilare il metodo rallentando notevolmente l'esecuzione.
Nell'esempio precedente abbiamo guadagnato, oltre che sul tempo di esecuzione, anche sul numero di oggetti allocati lasciando all'applicazione più ossigeno (memoria) per poter poi lavorare con i dati.
Con il primo codice (su 100 record) abbiamo caricato 12 assembly, 914 classi, 2339 metodi, allocato 34786 managed object, 1286520 bytes, "subendo" due operarazioni del GC.
Con il secondo codice (su 100 record) abbiamo caricato 12 assembly, 914 classi, 2343 metodi, allocato 20232 managed object, 744300 bytes, "subendo" una sola operarazione del GC.
Con il primo codice (su 1000 record) abbiamo caricato 12 assembly, 915 classi, 2344 metodi, allocato 179695 managed object, 6564420 bytes, "subendo" sette operarazioni del GC.
Con il secondo codice (su 1000 record) abbiamo caricato 12 assembly, 915 classi, 2346 metodi, allocato 32835 managed object, 1093684 bytes, "subendo" una sola operarazione del GC.
In soldoni nel secondo test passiamo da 179.695 oggetti allocati su 6,5 Mb a 32.835 oggetti allocati su 1.1 Mb....oltre ad andare più forte, abbiamo allocato 1 Mb di bytes managed contro 6,5, limitando a 1 l'intervento del GC rispetto a 7.
Questi dati sono estratti dal file Applicazione.stat: nella versione 2.0 del .NET CF viene creato un file .stat per ogni applicazioni mentre nella 1.0 il file era unico per tutte le applicazioni .NET eseguite. Il file viene creato all'uscita dell'applicazione.
Alla prossima
Come far passare una query su 100 record da 1,021 secondi a 0,35 ? Semplice: non usare DataSet/DataTable ma appoggiarsi ai Base Table Cursor di SQL Server CE 3.0 (aka SQL Server 2005 Mobile).
Stanotte ho fatto un po' di test su DB da 100 a 10.000 record. Oggi proseguo calcolando anche i pesi in memoria. Fra stasera e domani pubblico i risultati e nei prossimi giorni il codice che ho usato. Per una intro ai Base Table Cursor si veda http://thinkmobile.it/blogs/rob/archive/2005/10/31/4994.aspx
Questo non vuol dire che non si debba mai usare un DataSet/DataTable e si debba scrivere sempre tutto a mano anche in un progetto semplice con 100 record e 3 tabelle, ma semplicemente capirne le implicazioni per usare queste tecniche solo quando non introducono lentezza/pesantezza. La bellezza di VS 2005 e del .NET CF sta proprio in questo: consente di utilizzare tecniche semplici da implementare per tutti i casi non complessi, ma scendere nel "bit" facendo le cose per benino :-) per tutti gli scenari più complessi....e, facendo le cose per bene, passare da una modalità a l'altra senza impazzire.
More Posts
Next page »