2012-03-16 8 views
8

Operacja usunięcia sprawdza się sama, jeśli wskaźnik ma wartość nullptr. Czy istnieje jakiekolwiek obciążenie wydajności podczas wywoływania delete na nullptr bez sprawdzania go samemu?Usuwanie nullptr - narzut wydajności?

delete ptr; 

lub

if (ptr != nullptr) delete ptr; 

Które z powyższych wykonywana szybciej jeśli PTR nullptr?

+7

Ten ostatni jest zbędny, więc ewentualne różnice w prędkości na bok, jest gorzej. – ildjarn

Odpowiedz

18

Jak zwykle zależy to od kompilatora.

Używam MSVC, który kompiluje obie linie do dokładnie tego samego kodu.

Reguły mówią, że jeśli wskaźnik ma wartość null, usunięcie nie przyniesie efektu. Więc jeśli tego nie zaznaczysz, kompilator i tak musi.

2

Jest to zdecydowanie przypadek nadmiernej optymalizacji. W każdym nowoczesnym procesorze różnica wynosi kilka nanosekund.

Wykonując sprawdzenie, kod unika narzutów połączenia (do procedury usuwania biblioteki). W 99% przypadków niewielka dodatkowa złożoność kodu źródłowego (nawiasy klamrowe, potencjalne literówki != itp.) Jest większym problemem niż dodatkowy czas wykonania.

+0

Kontrola musi być w wygenerowanym kodzie, przed wywołaniem biblioteki ':: operator delete()', ponieważ kompilator nie może wywoływać destruktora, jeśli wskaźnik ma wartość 'null'. –

2

Nie, nie ma żadnych kosztów ogólnych, gdy nie sprawdzasz, czy ptr jest nullptr.

W przypadku ręcznego sprawdzania, ta sama kontrola jest wykonywana dwukrotnie, chociaż jest to pomijalne, w porównaniu do kosztu wywołania systemowego, można się spodziewać, że wartość ptr nie jest zerowa.

+3

Ponadto, jeśli już używasz C++ 11, może warto rozważyć niestosowanie usuwania w ogóle i zamiast tego używać inteligentnych wskaźników? –

+1

C++ 11 nie jest konieczne - Boost ma dobre inteligentne wskaźniki od lat. : -] – ildjarn

+0

Oczywiście! Ale kiedy leżą tuż pod tobą, nie masz więcej wymówek, aby nie używać ich w większości standardowych przypadków :) –

2

Który z powyższych elementów działa szybciej, jeśli ptr ma wartość nullptr?

Zakładając, że czek nie zostanie zoptymalizowany, górny będzie szybszy. Jeśli zostanie zoptymalizowany, nie będzie szybszy. Pozostaw to kompilatorowi.

Powiązane problemy