Newsgroup: it.comp.lang.delphi
Titolo: Ottimizzazione avvio applicazione

Sto cercando di ottimizzare i tempi di caricamento (mediante delle
outputdebugstring e il DebugView di sysinternals) di un'applicazione ma ho
dei 'buchi' teorici di delphi.
La sequenza che immagino è:
Dpr -> Application.Init -> creazione form -> Application.run -> Show della
finestra principale.
Quello che non capisco è perchè ci mette circa 2,5 secondi per passare dalla
Application.run alla show della form principale.
Ho seguito passo passo dopo il .Run (con F7) e ho visto che fa entra
solamente nella unit DBOleCtl per eseguire poche istruzioni e poi richiama
la FormShow.
Cosa può essere?
-- 
Lis
Mercatino: 
http://snurl.com/sito_lis
FAQ di it.comp.lang.delphi: 
http://snipurl.com/faq_icld

quanta roba hai in autocreate?
A

)

 derivati) per i quali la proprietą Connected č impostata a True.
Rispondo ad entrambi:
ecco i vari passi che vedo all'avvio, con i relativi tempi.
Il punto incriminato č tra Dpr-6 e MainShow-begin (quasi 2,5 sec)
0.00000000  Dpr - begin	
0.01281783  Dpr - 1	
0.01290946  Dpr - 2	
0.02887546  Dpr - 3	
0.20099677  Dpr - 4	
Fino a qua ho creato due datamodule e fatto assegnamenti vari. velocissimo.
Ora sto per creare la form principale (application.createform)
1.76176330  MainCreate - begin	
Qua inizia la FormCreate della finestra principale
1.76241114  MainCreate - 1	
1.76346016  MainCreate - 2	
1.76396721  MainCreate - 3	
1.76788670  MainCreate - 4	
1.80891733  MainCreate - 5	
1.81328465  MainCreate - 6	
1.86366647  MainCreate - 7	
1.86375447  MainCreate - 8	
1.86383968  MainCreate - 9	
1.86393299  MainCreate - end	
...e qua finisce. Ora nel Dpr creo altre 3 form
1.86400087  Dpr - 5	
...e anche qua č tutto ok e velocissimo.
Dpr-6 č l'istruzione subito prima di Application.Run
2.18849686  Dpr - 6	
e dopo la .Run salta alla FormShow della mainform, salto che perņ impiega
circa 2,5sec
4.57918646  MainShow - begin	
4.67165017  MainShow - 1	
4.67188064  MainShow - 1a	
4.67317243  MainShow - 1b	
4.67326741  MainShow - 1c	
5.82470258  MainShow - 2	
5.82535825  MainShow - 3	
5.82571360  MainShow - 4	
5.82606253  MainShow - 5	
5.82613796  MainShow - 6	
5.85289108  MainShow - end	
Idee?


> Idee?
Secondo me dipende dal balordo sistema di allocazione memoria di Delphi.
Prova ad aggiungere alle unit del progetto la ShareMem. Dovresti notare una
certa differenza.



:-OOOOOOOOOOOOOOOO
Ho aggiunto la unit (in cima all'elenco delle uses, come specificato dalla
documentazione) nel dpr e nella mainform e ora il tempo di caricamento
*totale* dell'applicazione è di circa 2sec!!!
Fantastico!! Ci sono delle controindicazioni ad usare questa unit? Devo
includerla in tutte le form o è sufficiente includerla nel dpr?


 includerla in tutte le form o è sufficiente includerla nel dpr?
nessuna controindicazione, nessun effetto collaterale ;) ..devi solo
distribuire anche una dll, nella stessa directory dell'exe. E' la
borlndmm.dll.

 visto? :)
'spe...ho parlato troppo presto. Anche senza sharemem, quando avvio
l'applicazione a volte ci mette 2 secondi, altre volte 5...ci dev'essere
qualche meccanismo di cache di windows che velocizza il tutto. Continuo a
fare un pò di prove


 Idee?
Secondo me, oltre ad elencare il numero di righe che hai all'interno del 
progetto principale (che non è un'informazione utilissima), dovresti più 
che altro descrivere di quale tipo di applicazione si tratta, se fai uso 
di database, quali componenti utilizzi e così via.
Comunque, non capisco cosa c'entri la unit ShareMem in tutto questo...


 certa differenza.
Sì, un calo generale di prestazioni... ;-)


 Sě, un calo generale di prestazioni... ;-)
al contrario.

 di database, quali componenti utilizzi e cosě via.
oltre al numero di righe (che poi era un numero di sequenza, non di riga) ho
anche indicato i punti fondamentali in cui creo form e datamodule.
La form principale č in effetti un pň pesante, contiene un ocx, dei
componenti per la visualizzazione di file e cartelle tipo explorer (Jam), un
Datasource associato ad una TTable e un pň di oggetti di interfaccia (image
list, pannelli, toolbar, menu).
La creazione di quel form č pressochč immediata (l'istruzione
application.formcreate dura pochissimo, a meno che non sia creato tutto
insieme ma la creazione dei vari oggetti venga completata tra
l'application.run e il mainform.formshow (punti Dpr-6 e MainShow-begin)


 l'applicazione a volte ci mette 2 secondi, altre volte 5...
Infatti la presenza o meno di ShareMem non dovrebbe influrire per niente.

Consiglio a tutti di provare la FastShareMem (basta cercare con Google), e'
un gestore di memoria alternativo alla Sharemem e, ovviamente, al pessimo
gestore di default di Delphi, che garantisce prestazioni ancora migliori
nell'allocazione/deallocazione di tutte le risorse dinamiche dei programmi.
Io la uso da un paio d'anni, con eccellenti risultati.
A proposito della ShareMem, ricordo che quando la usavo con Win98, mi
risolse problemi di AV alla chiusura del programma, che invece si
verificavano col gestore di memoria predefinito di Delphi. AV che,
ovviamente, non dipendevano dal mio software, ma da qualche balordo
meccanismo interno all'applicazione.

Ecco il link:
http://www.codexterity.com/fastsharemem.htm
e parte dell'introduzione:
What is FastSharemem?
Most Delphi developers are resigned to the fact that to use
dynamically-allocated memory (objects, strings etc) across DLLs,
Sharemem.pas must be included, Borlndmm.dll must be bundled with their
application, and its performance costs paid.
In fact, this is one of Delphi's weaknesses. When using DLL's and Sharemem,
all memory allocations are slowed down, including simple string operations
and object creation.
FastSharemem attempts to provide an alternative.  It is a fast, lightweight
replacement for Sharemem.pas and Borlndmm.dll which requires no runtime DLL,
and incurs virtually no performance penalty. It can be downloaded here. For
a discussion of why you might require Sharemem or a replacement, see the
page on memory management.
FastSharemem has also been reported to fix unsolved "Invalid Pointer
Operation" or Runtime Errors with Sharemem/Borlndmm.dll. If you're using
Sharemem properly and still getting these errors, then you might want to try
FastSharemem.

 con e senza sharemem.
Come giustamente dice Marco, la presenza di ShareMem, al limite, le
prestazioni le degrada.  Il meccanismo usato da Delphi per l'allocazione
dinamica è tutt'altro che balordo, anzi, è più veloce che ricorrere
continuamente alle API Windows. ShareMem non fa altro che instradare tutte
le richieste di allocazione verso Borlndmm.dll, riducendo le prestazioni a
volte anche di 10 volte. I blocchi (heap) allocati da Delphi, invece,
vengono richiesti/rilasciati mediante le funzioni
VirtualAlloc()/VirtualFree(), ma la loro gestione è in mano ad un allocatore
"interno".

 l'application.run e il mainform.formshow (punti Dpr-6 e MainShow-begin)
Domanda banale: hai inserito codice nell'evento OnShow della form? :-)


 Domanda banale: hai inserito codice nell'evento OnShow della form? :-)
Risposta banale, incollo dal mio post precedente ;-)
"
...e anche qua è tutto ok e velocissimo.
Dpr-6 è l'istruzione subito prima di Application.Run
2.18849686  Dpr - 6	
e dopo la .Run salta alla FormShow della mainform, salto che però impiega
circa 2,5sec
4.57918646  MainShow - begin	
4.67165017  MainShow - 1	
4.67188064  MainShow - 1a	
"
Quindi nella FormShow ho inserito del codice (che impiega circa 1,3 sec per
essere eseguito), e la mia domanda è perchè impiega circa 2,5sec per passare
dal .Run all'inizio del FormShow


 meccanismo interno all'applicazione.
Non ne ho l'assoluta certezza, ma credo che il gestore di memoria 
"predefinito" e quello incluso in ShareMem non siano poi cosě diversi; 
la unit ShareMem non serve ad utilizzare un gestore di memoria 
alternativo o "trendy", quanto piů a condividere lo stesso gestore di 
memoria per l'eseguibile e le DLL (create con Delphi) eventualmente 
linkate, evitando che i rispettivi gestori di memoria, replicati in ogni 
modulo (salvo diversamente specificato attraverso ShareMem), si 
calpestino a vicenda magari eliminando le risorse appartenenti all'uno 
che vengono utilizzate anche dall'altro.
Se nella tua applicazione hai fatto uso di DLL create separatamente con 
cui l'eseguibile condivide strutture come stringhe (non ShortString) e 
classi - per citare le piů comuni - allora l'uso di ShareMem č 
obbligatorio per garantire il corretto funzionamento dell'applicazione; 
in caso contrario, č facile ottenere eccezioni del tipo "Invalid pointer 
operation", ma *non* sono dovute a imperfezioni e balordaggini del 
memory manager che Delphi incorpora nell'applicazione per default, 
quanto piů ad un uso scorretto dello stesso, che per quanto mi riguarda 
non ha mai dato problemi prestazionali o di errori sconosciuti...tranne 
ovviamente quando non l'ho usato come si doveva (non posso quindi 
prendermela con lui, poveretto!). :-)
Ciao!


Concordo pienamente con te Marco. La tua definizione delle funzionalità
della ShareMem è più che corretta.
Cmq Lis, sicuro di non avere nulla nell'evento Paint della form?
Saluti
    Luigi

 
Sě, gli eventi interessati li ho messi tutti. Comunque non č un problema
enorme, per fortuna si tratta di un paio di secondi di troppo e basta
