windows - Overhead forbundet med OutputDebugString i release build

Indlæg af Hanne Mølgaard Plasc

Problem



Er der en betydelig overhead forbundet med at kalde OutputDebugString i release build?

Bedste reference


Målt - 10M opkald tager omkring 50 sekunder. Jeg tror, ​​at det er betydeligt overhead for ubrugt funktionalitet.


Brug af en makro kan hjælpe med at slippe af med dette i release build:


#ifdef \_DEBUG
    #define LOGMESSAGE( str ) OutputDebugString( str );
#else
    #define LOGMESSAGE( str )
#endif


Ikke kun fjerner opkaldene, men også parametervurderingen og tekststrengene fjernes helt og du kan ikke se dem i den binære fil.

Andre referencer 1


Jeg skriver dette længe efter dette spørgsmål er blevet besvaret, men de givne svar savner et bestemt aspekt:


OutputDebugString kan være ret hurtig, når ingen lytter til dens output. Hvis du har en lytter der kører i baggrunden (det være sig DbgView, DBWin32, Visual Studio osv.) Kan det gøre det mere end 10 gange langsommere (meget mere i MT-miljøet). Årsagen er, at disse lyttere kører rapporthændelsen, og deres håndtering af arrangementet sker inden for rammerne af OutputDebugString-opkaldet. Hvis flere tråde kalder OutputDebugString samtidigt, bliver de desuden synkroniseret. For mere, se Se ud: DebugView (OutputDebugString) & Performance. [3]


Som en sidebesked mener jeg, at medmindre du kører en real-time ansøgning, bør du ikke være så bekymret over en facilitet, der tager 50 sekunder at køre 10M opkald. Hvis din log indeholder 10M indgange, er de 50 sekunder spildt Mindst af dine problemer, nu hvor du skal analysere dyret på en eller anden måde. En 10K log lyder meget mere fornuftig, og skaber det vil kun tage 0,05 sekunder som per sharptooths måling.


Så hvis din produktion er inden for en rimelig størrelse, skal det ikke gøre dig så ondt at bruge OutputDebugString. Husk dog en afmatning, når en person på systemet begynder at lytte til denne output.

Andre referencer 2


Jeg havde læst i en artikel, at OutPutDebugString internt gør få interessante ting:



  1. Opretter \ Åbner mutex og venter uendeligt, indtil mutex er erhvervet.

  2. Passerer dataene mellem applikationen og debuggeren sker via en 4kbyte klump af delt hukommelse med en Mutex og to Event objekter, der beskytter adgangen til det.



Selvom debuggeren ikke er vedhæftet (i frigivelsestilstand) er der betydelige omkostninger involveret i at bruge OutputDebugstring med brugen af ​​forskellige kernelobjekter.


Performance hit er meget tydeligt, hvis du skriver en prøvekode og test.

Andre referencer 3


Jeg har ikke set et problem i snesevis af server-side release mode apps gennem årene, som alle har indbyggede metrics. Du kan få indtryk , at det er langsomt, fordi de fleste af de debug-catcher-applikationer, du kan finde (DBWIN32 et al), er temmelig langsomme til at smide dataene op på skærmen, hvilket giver indtryk af lag.


Selvfølgelig har alle vores applikationer denne funktion deaktiveret som standard, men det er nyttigt at kunne tænde det i feltet, da du derefter kan se fejlfejl output fra flere programmer, serialiseret i noget som DBWin32. Dette kan være en meget nyttig fejlfindingsteknik til fejl, der involverer kommunikationsapplikationer.

Andre referencer 4


Forlad aldrig OutputDebugString () opkald i en udgivelsesbygning. Fjern altid dem enten ved hjælp af #ifdef-udsagn, eller giv en anden kontakt for at få dem slukket.


Hvis du forlader dem, skal du deaktivere dem som standard og aktivere dem kun på forespørgsel, da ellers vil din app gøre det svært at fejle andre apps, der fungerer fint (dvs. kun outputfejldata på forespørgsel).


Theres DebugView for at fange output fra apps, men selvfølgelig er det kun godt, hvis ikke alle apper snakker sammen uden nogen god grund. [4]

Andre referencer 5


Hvorfor ikke måle det selv? Kompilér følgende kode, kør den & tid det. Fjern derefter opkaldet til OutputDebugString, genkompil og genopret. Skal tage imod tre minutter af din tid.


   #include <windows.h>

    int main() {
        const int COUNT = 1000000;
        int z = 0;    
        for ( unsigned int i = 0; i < COUNT; i++ ) {
            z += i;
            OutputDebugString( "foo" );
        }
        return z;
    }

Andre referencer 6


Jeg var nysgerrig på dette emne, så jeg gjorde nogle undersøgelser.


Jeg har sendt resultaterne, kildekoden og projektfilerne, så du kan gentage testene for din opsætning. Omfatter at køre en frigivelsesprogram uden at overvåge OutputDebugString og derefter med Visual Studio 6, Visual Studio 2005 og Visual Studio 2010 overvågning OutputDebugString for at se, hvilke forskelle i ydeevne der er for hver version af Visual Studio.


Interessante resultater, Visual Studio 2010 behandler OutputDebugString information op til 7 gange langsommere end Visual Studio 6.


Fuld artikel her: Hvad koster OutputDebugString? [5]