Perché il programma di debug è rallentato così tanto quando si utilizza il debug delle voci del metodo?

Sto usando le interfacce jdi per creare un debugger e quando utilizzo MethodEntryRequests per abilitare la tracciamento del metodo, il programma debugato rallenta per il fattore decine. Ho impostato il filtro per il thread principale e il criterio di sospensione su SUSPEND_EVENT_THREAD. Classfilter è limitato e se stampo qualche evento ricevuto non ne mostra più di una dozzina, quindi non dovrebbe riceverne troppi. Sto debug a livello locale e avendo tipo followind di riga di comando con il programma Java debug:Perché il programma di debug è rallentato così tanto quando si utilizza il debug delle voci del metodo?

-Xdebug -Xrunjdwp:transport=dt_socket,suspend=y,server=y,address=1337

fonte

2009-04-15 JtR

buona domanda. Ho notato che i breakpoint di entrata del metodo rallentano notevolmente quando eseguo il debug di programmi Java con Eclipse. Spero che qualcuno abbia la risposta! –

La situazione è migliorata nelle ultime versioni di Java o è la stessa? – WSS

La risposta breve è che l'esecuzione viene eseguita attraverso l'interprete quando vengono impostate le voci del metodo. Non penso che ci sia comunque intorno a questo ...

Questo era il caso per tutto il codice in esecuzione in modalità di debug ma it was enhanced in 1.4 ... ora HotSpot funziona per il debug a "piena velocità" tranne nel caso di entrate e uscite del metodo, punti di controllo e quando singoli passi o metodi che contengono punti di interruzione.

fonte

2009-04-24 22:08:04 Ichorus

Ha davvero senso solo ... HotSpot fa ogni sorta di cose belle nel codice di compilazione per accelerarlo (compresi i metodi di allineamento che offusca i confini tra i metodi coinvolti). Inoltre, è adattabile, quindi tra le esecuzioni di come un metodo può essere modificato. Sicuramente non è qualcosa che si vuole avere quando si è nel mezzo del debug. – Ichorus

Parto dal presupposto che il debugger ha bisogno di svegliarsi per ogni chiamata di metodo per vedere se corrisponde a quello (s) che sono stati selezionati per rompere. Perché deve verificare che ogni chiamata di metodo per una potenziale corrispondenza prima che possa eseguirla è molto più lenta di se non deve fare tutti questi controlli.

fonte

2009-04-21 03:26:38 lothar

2 motivi:

si deve aggiungere controlli su ogni metodo di immissione (non v'è alcuna opzione per modificare solo alcuni metodi)
metodo inline diventa impossibile (così piccole metodi corre 10-100x volte più lento)

stesso vale per i profiler e applicazioni .net

fonte

2009-04-26 12:36:19 Mash

Perché il metodo di inlining diventa impossibile? –

Poiché il metodo di inlining significa che non hai più quel metodo, il suo contenuto sarà INLINITO in tutti i punti da cui chiama e non si verificherà alcuna invocazione di metodo. Ma il debugger ha bisogno di quel metodo perché è il posto in cui sta prendendo il posto. – Mash

Sembra valido ma non abbastanza forte per me. Il metodo INLINED può ancora essere tracciato dal debugger? Tecnicamente dovrebbe conoscere il metodo di inclusione in cui è in linea? –

Perché il programma di debug è rallentato così tanto quando si utilizza il debug delle voci del metodo?

risposta

Problemi correlati