Cześć, mam takie pytanie:
czy sprawdzenie warunku typu if(zmienna) wykona się szybciej niż sprawdzenie warunku: if(!zmienna) tzn. czy użycie dodatkowo operatora negacji w tym konkretnym wypadku zwolni działanie programu?
Nie. Zresztą wygeneruj sobie kod asemblera z obu przypadków i porównaj. Dla procesora to jest tak czy siak CMP a potem skok warunkowy. W tym przypadku różnica to tylko instrukcja JNZ lub JZ, więc z technicznego punktu widzenia różnicy być nie powinno.
Dzięki. Niestety nie znam się na asemplerze i ciężko mi to weryfikować.
To skąd pomysł żeby się zastanawiać nad taką optymalizacją? o_O Przecież nawet gdyby faktycznie była tam naiwna operacja NOT to zyskałbyś na tym jakieś pojedyncze cykle procesora.
czy sprawdzenie warunku typu if(zmienna) wykona się szybciej niż sprawdzenie warunku: if(!zmienna) tzn. czy użycie dodatkowo operatora negacji w tym konkretnym wypadku zwolni działanie programu?
Zależy - jeżeli mowa o architekturze x86 oraz x86-64 to na 100% (no, powiedzmy - 99%; zależy, czym ta zmienna jest) zostanie to skompilowane prawie że identycznie, jedynie różnica będzie w jednym opcodzie: jz
-> jnz
(jak wspomniał @Shalom).
Natomiast jeżelibyś kompilował np.na JVM czy jakąś inną architekturę, to może być różnie - założę się jednak, że to mimo wszystko będzie niemierzalna różnica :P
A ja przy okazji zapytam czy jest są jakieś różnice między case a if, poza czytelnością kodu ?
Jeśli musisz używać case to znaczy że coś z tym kodem może być nie tak, ale to zależy od ilości "przypadków".
Jest. Case porównuje Ci konkretne wartości, natomiast w ifach możech zawrzeć przedziały wartości. Ale to chyba wiesz, nie?
Poza tym - w asemblerze też pewnie będzie to na poziomie instrukcji:
if - stosowanie różnych w zależności od warunków konkretnego ifa, może przypaść więcej instrukcji na cały warunek.
switch - je lub jne (ostatecznie jz i jnz)
Edit: widzę, że Shalom mnie ubiegł :D
switch
może być też skompilowane jako tzw. jump-table, czyli skok pod adres pobrany z tablicy, do której indeksem jest wartość pod case
. (mniej więcej)