[OT] Performance delle applicazioni .NET Windows Forms

[dops]

ciao, non riesco a capire perchè le mie applicazioni (winform) risultano lente..
Un esempio su tutti: creo una form con 15 controlli textbox, F5.. e noto sempre che visualizzo il rendering dei campi.. praticamente per un attimo vedo le textbox grigie (colore tipico delle form) e poi bianche.. questo mi capita sempre, non solo al primo avvio dell'applicazione.. quando i campi sono un numero abbastanza alto (15 campi sono tanti ?) ..non sò se mi sono spiegato.. spero di sì..
altra cosa che mi capita è appunto che il primo avvio delle applicazioni winform è sempre molto lento..
la differenza tra lento e veloce la deduco dal fatto che altri software fatti con altre linguaggi ed altri framework, sulla stessa macchina, pur essendo belli grossi (molte form, molti campi, molto tutto) sono veloci anche al primo avvio e non si verifica quella cosa dei campi che ho cercato di spiegare prima..
maè una cosa che capita solo a me o l'avete notato anche voi ?

[alka]

Il caricamento del runtime e la compilazione JIT del codice intermedio (IL) dei metodi invocati all'avvio, col preventivo caricamento degli assembly e le relative verifiche di sicurezza effettuate "di rito" dal CLR, richiedono un tempo di startup maggiore rispetto ad applicazioni native.

E' uno dei prezzi che si paga, ma ovviamente si beneficia anche dei vantaggi nell'uso del .NET Framework descritti, che mancano in altri linguaggi (lo sviluppo in .NET offre senz'altro maggiore flessibilità e scalabilità rispetto a VB6, per fare un esempio), mentre il vantaggio si riduce notevolmente, o scompare e addirittura arretra in certi casi se comparato con altri linguaggi e tecnologie).

Se poi consideriamo che tutti i controlli in un'applicazione Windows Forms hanno un handle, anche quando non è necessario (non esistono, ad esempio, i Graphic Control della VCL di Delphi), sicuramente c'è un'occupazione maggiore di risorse, oltre ad una "pesantezza" maggiore in presenza di molti controlli, cioè nel panorama che hai descritto.

In conclusione, si tratta di un effetto del tutto normale.

Ciao!

[dops]

Originariamente inviato da alka

In conclusione, si tratta di un effetto del tutto normale.

e molto fastidioso aggiungerei.. quando presenti un'applicazione con questo tipo caratteristica, non è che viene vista molto di buon occhio..
soluzioni insomma non ce ne sono?

[alka]

Originariamente inviato da dops
e molto fastidioso aggiungerei.. quando presenti un'applicazione con questo tipo caratteristica, non è che viene vista molto di buon occhio..
soluzioni insomma non ce ne sono?

Che dire... è un effetto che si nota, ma non gli ho mai attribuito una connotazione così problematica.

Forse, usando il tool NGen, quindi generando le immagini native del codice intermedio del programma e delle librerie utilizzate, si ottiene uno "startup" più breve, però si perde successivamente l'ottimizzazione del CLR applicata nella conversione del codice IL in codice macchina basandosi sullo stato attuale dell'ambiente operativo (RAM disponibile, risorse allocate, ecc.).

Insomma, è un "problema" intrinseco alle applicazioni .NET. Per evitarlo completamente, occorre indirizzarsi verso un'altra architettura o usare degli "escamotage", o attendere che vengano effettuate sul CLR ottimizzazioni pesanti al punto che il problema vada a scomparire.

Ciao!

[dops]

Originariamente inviato da alka
Che dire... è un effetto che si nota, ma non gli ho mai attribuito una connotazione così problematica.

Forse, usando il tool NGen, quindi generando le immagini native del codice intermedio del programma e delle librerie utilizzate, si ottiene uno "startup" più breve, però si perde successivamente l'ottimizzazione del CLR applicata nella conversione del codice IL in codice macchina basandosi sullo stato attuale dell'ambiente operativo (RAM disponibile, risorse allocate, ecc.).

Insomma, è un "problema" intrinseco alle applicazioni .NET. Per evitarlo completamente, occorre indirizzarsi verso un'altra architettura o usare degli "escamotage", o attendere che vengano effettuate sul CLR ottimizzazioni pesanti al punto che il problema vada a scomparire.

Ciao!

capisco.. ok grazie mille