Profiler senza debug

[t.simoncini]

Attualmente, per ottenere i valori di profiler per le procedure dell'applicazione è necessario avere il debug attivo.

1.png (48.79 KiB) Viewed 6423 times

Sarebbe comodo che i valori di profiler delle singole procedure venissero anche quando il debug è disattivo.

2.png (24.85 KiB) Viewed 6423 times

Questo perchè in caso di applicazioni complesse con molto codice, la scrittura del debug rallenta in modo notevole l'applicazione, rendendo di fatto notevolmente falsati i valori di profiling.
Disattivando il debug, si hanno delle performance molto più vicine a quelle di produzione, ma non si riesce a capire quali sono le procedure che effettivamente rallentano l'applicazione.

[lucabaldini]

Quello che dici è vero, con il debug attivo tutto è più lento ed è così per qualunque sistema. Anche InDe, se compilato in debug, è mooooooooolto più lento... però in debug riesco a capire dov'è più lento e renderlo più veloce anche in Release.

Se una procedura ci mette 5 secondi senza debug e 20 con il debug posso comunque vedere nel debug dove è l'80%-90% del tempo...

D'altronde se il debug è spento non potresti vedere perché perdi tempo ma sapresti solo che il click su una box ha richiesto 3 secondi.

Non capisco che vantaggio ci sarebbe a mostrare solo i tempi ma non poter sapere dove e perché si perdono.

Tieni conto che puoi anche disabilitare il debug su procedure singole. Se, per esempio, hai la funzione creaCodice che viene chiamata migliaia di volte e sei sicuro che sia già ottimizzata e corretta, toglila dal debug... così i dati sono più vicini al reale e puoi vedere altri rallentamenti. Almeno questo è il modo in cui opero io di solito.

[t.simoncini]

Non mi riferivo all'applicazione compilata senza debug, ma compilata CON debug e impostato disattivo (come immagine 2).

"il click su una box ha richiesto 3 secondi" riesco già a vederlo adesso come da immagine. Vorrei capire quali procedure, attivate dal click impiegano più o meno tempo.

Il problema con il debug attivo, è che non so se l'80% del tempo è stato impiegato per eseguire la procedura o scrivere le info di debug.
Prendi come esempio due procedure: in una c'è solo una select che impiega 1 secondo, nell'altra c'è un algoritmo molto lungo e complesso.
Con debug disattivo, la seconda procedura impiega il 5% del tempo. Con debug attivo, la scrittura di tutte le info di debug rallentano l'esecuzione e la procedura impiega 9 secondi (90 % del tempo).

In generale, quando faccio profiling, non mi interessa sapere in quali IF è entrata l'applicazione o quali valori avevano le variabili. Mi interessa sapere quali procedure portano via tempo (ripeto, in generale).
Solo in seguito vado ad indagare il codice.

[lucabaldini]

Non credo di aver capito. Come faccio ad ottenere le info su quali proc ho visto se non posso raccogliere i dati di debug?

Il problema è che se il debug è spento io non raccolgo item di debug... ma sono proprio gli item di debug che mi dicono in quali procedure sono entrato e quando e perché ne sono uscito.

Comunque quello che chiedi si può già fare. E' sufficiente cambiare il livello di log in fase di compilazione. Cosa che, tra l'altro, scrive molte meno righe di debug e rende il codice generato più "vicino" a quello effettivo. Prova a cambiare il valore nella combo mostrata nella videata di build da statements a "procedure calls" che è proprio quello che vorresti ottenere.

[t.simoncini]

Ok. Forse ho interpretato male come vengono generati i dati di profiler.
Faccio un po' di test con l'opzione che mi hai segnalato.
Grazie per ora.

[t.simoncini]

Confermo che la soluzione del livello di debug "procedure calls" risolve il mio problema.
Grazie.

[lucabaldini]

Ottimo! :-)

[simoned]

Buongiorno, mi inserisco nel thread per aggiungere che sarebbe comodo poter avere nel "riepilogo" nella parte inferiore del debug anche le query eseguite, con quante volte è stata eseguita e il tempo totale.. ovviamente se la stessa query potrebbe essere stata eseguita 10 volte con dei parametri diversi ma mi interesserebbe vederla elencata 1 volta con call count=10... vedi esempio sotto (il "(4 records)" potrebbe essere la somma di tutti i record restituiti nelle 10 chiamate).

Debug Window1.png (152.32 KiB) Viewed 6141 times

eventualmente le query nel "riepilogo" potrebbero essere visibili opzionalmente (un po come i tempi di durata delle richieste che sono visibili solo se clicco l'icona del timer)

inoltre sarebbe comoda un livello di log "procedure calls + query" che mostri nel debug solo le chiamate alle procedure (come ora) con in più le query eseguite.

Aggiungo che sarebbe molto comoda la possibilità di selezionare a runtime il livello di log in modo da compilare l'applicazione con il massimo livello di log,poi a runtime posso mettere solo "procedure calls+query" e vedo dove si perde tempo e se voglio analizzare qualcosa più approfonditamente imposto a runtime il livello massimo e rieseguo l'operazione (ad esempio apertura di una form) per vedere esattamente il problema.
Ho visto che esiste DTTLoglevel ma non cambia niente.. sbaglio qualcosa?

grazie

[lucabaldini]

Per quanto riguarda proc+query ci devo pensare... potrebbe essere utile se si vuol sapere subito dove si perde tanto tempo...

Per quanto riguarda il fatto di attivare a compile time il massimo livello di log poi a run-time filtrare si può già fare. Se compili con il massimo livello puoi usare le due combo in alto a destra nella videata di debug per "filtrare" i dati... così vengono mostrati solo i dati che ti interessano.

Attenzione, il debug comunque raccoglie tutti gli oggetti di debug... quello che fai in questo modo è solo "filtrare" i dati nella videata di debug.

Questa cosa non è uguale al cambiare il valore della combo nella videata di build... quella combo ha impatto sul codice generato (in pratica vengono aggiunge le istruzioni in più che raccolgono i dati di debug del livello indicato in fase di compilazione).

Se cambi, da codice, il DTTLogLevel, da quel momento in poi il debug raccoglie solo i dati richiesti... anche qui il livello non può aumentare rispetto a quello indicato a compile time... se a compile time hai detto "logga solo le proc" non puoi vedere gli statement dato che manca propio il codice (che sarebbe stato scritto da InDe) per raccogliere le info di debug delle righe di codice.

Quindi, riassumendo, occorre compilare a compile time con il massimo livello.. poi puoi filtrare (sia da codice che dalla videata di debug).

Abbiamo creato l'attività NPQ02205 per tenere conto di questa conversazione. Quando verrà valutata, potrai seguirne l'andamento con Instant Developer Roadmap.

[t.simoncini]

potrebbe essere utile se si vuol sapere subito dove si perde tanto tempo...

E' proprio a quello che serve il profiler... :-)