Newsgroup: it.comp.lang.visual-basic
Titolo: lentezza software vb.net

Ciao, sto realizzando un piccolo gestionale  con 
ado.net
 ( dataset, binding 
etc)
All'interno della form sto utilizzando un tabcontrol dove ho messo le varie 
maschere e mi rondo conto che il pc sta rallentando in modo mostruoso...
Sarebbe meglio mettere le maschere in form diversi?
E' dovuto all'eccessivo uso di binding o alla scarsa potenzialit� 
dell'ambiente di sviluppo?
Al momento il vb2008 express sta occupando in ram 211M e 225M di ram 
virtuale...
Grazie

 Grazie
la prima volta che lo lanci in un nuovo pc si auto compila e la volta
successiva và molto più veloce.
Le memoria ci vuole...e non è veloce come un c++ per sua stessa
caratteristica costruttiva.
Lo devi paragonare con tutti i vari linguaggi e tecnologie che mettono
di mezzo un "simil virtual machine" !...java per esempio!
E comunque non puoi farlo girare su un vecchio p3 con 1 Gb Ram!
Le caratteristiche minime sono:
http://msdn.microsoft.com/it-it/library/8z6watww.aspx
trovi info sui vari framework!
Poi comunque conta anche come sviluppi la tua
applicazione....considera che dotnet ti fa lavorare sempre disconnesso
e diventa importante pianificare come "chiedere" i dati (tutti ...la
tabella...solo pochi record)...e come aggiornarli (in genere sarebbe
preferibile invocare una stored e far fare il lavoro sporco al
db....ma ultimamente c'è un sacco di tecnologie per svincolare il
tutto ...vedi linq to qualcosa!)
la risposta quindi è.....dipende!
:o)

 ha scritto nel messaggio 
news:eacba506-0b1b-4eb3...@32g2000yqj.googlegroups.com...
CUT
la risposta quindi �.....dipende!
:o)
� quel dipende che mi preoccupa....faccio caricare tutta la tabell in 
memoria, ma a prescindere dall'uso dell'exe, proprio il sistema di sviluppo 
rallenta alla grande.
Se apro la form principale con tutti i controlli lo schermo diventa bianco 
per 10 secondi circa poi inizia a disegnare la form con tutti i controlli.
Sto su xp sp2, 1G ram,2GHz di processore....
Grazie comunque, se alla fine l'exe generato � buono, cercher� di essere 
paziente durante la programmazione :D

 Sto su xp sp2, 1G ram,2GHz di processore....
Ci vorrebbero almeno 2 Gb...


Io uso senza problemi VS2005 e VS2008 su un Intel Centrino a singolo 
core del 2006 e 1 GB di Ram.
Secondo me c'� qualche altro problema. Che sia dovuto ad 
ado.net
? Magari 
la tabella � particolarmente grande e l'OP tenta di caricarla tutta in 
una datagrid.
Cos�, a spannazze non mi pare che il suo pc sia cos� sottodimensionato.
Nicola

 paziente durante la programmazione :D
Beh per quello che fai la ram sembra essere davvero mai troppa!
Se colleghi una tabella ad un dataset...e il dataset ad una
griglia...lavorando disconnesso....ti deve chiedere al server la
tabella e memorizzarla localmente!
ORA...
se il DB risiede sul solito pc....gli fai "fare" da :
Server
Client
Sistema di sviluppo
casomai...con qualche plugin per ascoltare la musica mentre
programmi...o con qualche p2p che in sottofondo "lavora"
Una cosa del genere il mio pc la fa!
VISTA ultimate P4 3ghz single core 3 gbram HD Sata....
Il mio notebook pure
XP pro SP3 Centrino DualCore 1,66 4GB ram HD eide
Ebbene....sul centrino va più piano il tutto...la colpa?
Di Acer ...e del centrino....
Per sviluppare è come per fare grafica...più il pc è "pompato" meno
aspetti!
Certo....a parità di codice....
se mi chiedi una tabella di 300.000 record...puoi avere anche un
cray...ma se deve passare da una rete tcp ingolfata il collo di
bottiglia è nello sviluppatore ! (non come sembrerebbe ad un profano
nella rete)
La conclusione è (imho)
Non è corretto collegare una tabella...nessun utonto sano di mente
consulterebbe la tabella generale del suo magazzino
prodotti....avrebbe un motore di ricerca interno per trovare quello
che cerca!
Nel primo caso si scorre tutti i 10.000 tipi di prodotti che vende per
trovare i bulloni di acciaio? FOLLE dopo 5 minuti ha lo sguardo
pallato e non vede più nulla!
Nel secondo caso ricerca(nei modi che vuoi): "Bullone" "Inox" "100mm"
e caso mai consulta una lista di 80/100 nomi!

Condivido tutte le osservazioni ma una cosa non mi � chiara: mentre sono in 
fase di programmazione( no di debug), non esistono record in 
memoria...soltanto la struttura delle tabelle e relative relazioni.
Visto che caricher� tutti in memoria( perch� comunque stiamo parlandi di un 
db access di 10 mega, quindi suppongo occuper� 10 mega in ram o giu per li) 
ado.net
 ha creato tutti i relativi controlli : binding, table adapter, 
binding navigator e altre diavolerie. Ho paura che quando vengono messi 
molti controlli su un form( specialmente se si usano vari tabcontrol) tutto 
il sistema rallenta ...:D

 il sistema rallenta ...:D
Rallenta perchè non sai cosa stai facendo!
Rallenterebbe QUALSIASI ALTRO linguaggio...anche l'assembler!
Il fatto che tu abbia "caricato tutto in memoria" è molto più grave di
quello che sembri!
Se carichi 10 M ....di dati....NON AVRAI mai un impegno di 10
Mb....perchè "appresso" c'è tutto quello che serve per lavorare con
quei dati!
Schiaffare un data adapter....significa non trascinare un "coso
strano" su una form....ma fare un sacco di cose che con vb6 ti saresti
fatto a mano....cn il rischio di sbagliare...e con il solito degrado
di prestazioni!
Vb6 ci faceva lavorare come ci pareva....anzi NON vb6...ADO
ADO.net a meno di sporadici tip...ci fa lavorare SEMPRE disconnessi!
Perchè fa questo? ci vuole male?
NO è che Microsoft insieme al 90% del mondo informatico a preso la
strada di internet e dell'ottica distribuita!
Un programma di contabilità viene visto come un servizio di previsioni
meteo come un carrello della spesa di un negozio online etc etc
Ossia
TANTI terminali che si collegano per eseguire operazioni.....in un
ottica del genere una logico SEMPRE connessa dà molti problemi:
esaurimento risorse, lentezza, ingolfamento rete, licenze, etc etc
Chi lavora con DB seri e non con Access questo problema oramai l'ha
affrontato e no è più un grande problema....
con C# o 
vb.net
costruisci un client ...una interfaccia....che a seconda delle finezze
si svincola più o meno dal DB ed ULTIMAMENTE...anche dal TIPO di db!
Un client lavora bene  ed è veloce...ed è scalabile(non dipende da
lui...ma dal server)
Però l'unica cosa che NON VUOLE fare un cliente.....è lavorare da
server!
Allora ci sono problemi...
se mi "tiri giù" tutte le tabelle...e lavori in locale...a che ti
serve ADO.net?
Continua ad usare DAO o ADO....e un po di stored per gestire conflitti
di update!
Inoltre se ti vuoi del male e vuoi tirar comunque giù tutto....le
query con ADO.net possono essere anche ASINCRONE....nel tuo caso
potrebbero dissipare la sensazione di blocco ...di "stò aspettando che
stò coso si muova!"
In sintesi
programare con 
ado.net
 NON VUOL dire schiaffare 3 componenti
dataadapter su un form!
Figuriamoci 30!
Significa capire come funzona...che logica c'è dietro!
E' una logica per chi non ha esperienze client/server MOLTO diversa!
Ti consiglierei mille tutorial ...dai libri di Balena che costano
veramente poco in edizione pocket agli articoli di 
http://www.visual-basic.it/
....ed un pc di sviluppo più perfomante!
Saluti!
Buon lavoro!

 Cos�, a spannazze non mi pare che il suo pc sia cos� sottodimensionato.
Beh, 2 Ghz se � un intel di prima generazione significa che � un P4 di prima 
serie.
Se � un AMD � un Athlon di prima serie se va bene con RAM DDR se non peggio, 
con un chipset
di quelli che se arrivano a 1,5 Gb di banda sulla RAM � una forza.

 il sistema rallenta ...:D
Ti ha giï¿œ risposto il buon Wodka, ma voglio aggiungere una cosa: un db 
di 10 MB puï¿œ contenere alcune decine di migliaia di record.
Staccarseli tutti in memoria ï¿œ sbagliato. Devi caricare ciï¿œ che serve, 
solo quando serve, e scaricarlo il prima possibile.
Poi, sono d'accordo con te, la macchina non sarï¿œ molto performante, ma 
non ï¿œ questione di quanta potenza hai, ma di come la sfrutti.
Nicola