Производительность: try vs if

[djyamato]

Здравствуйте, подскажите, что быстрее работает

try
{
myObject.doSomething();
}
catch(error:Error)
{
}


или


if(myObject)
{
myObject.doSomething();
}

[Dukobpa3]

if быстрее
try вообще выполнение всего блока тормозит раза так в три.

[MikroAcse]

Забудьте про try. В 99% случаев от него толку мало, а программу тормозит, да и количество кода увеличивает в разы.

[КорДум]

MikroAcse, как ты радикально. Try-catch полезен в ряде случаев, например при работе с ФС. Им также удобно отслеживать приходящие данные от сервера и выводить ответ в случае непредвиденного ответа в лог.

[belv]

Dukobpa3 , MikroAcse можете привести пример кода, как с помощью try/catch можно написать условие?

[Dukobpa3]

Речи о "вместо" не идет.
С помощью трай-кетчей условие - сомнительно, но в некоторых случаях реально. Сходу придумать сложно.
А наоборот: избежать трай-кетчей, обложив действие пачкой условий - можно и нужно.

[caseyryan]

Забудьте про try. В 99% случаев от него толку мало, а программу тормозит, да и количество кода увеличивает в разы.

Видимо на других языках ты никогда не писал..
в джаве без него вообще как без рук

[Dukobpa3]

Это псевдокод, просто для примера. Не пытайтесь собрать)

С проверкой:
if (File.exist(path)) {
file = File.read(path)
} else {
// файла нету
}


С трай-кетч
try {
file = File.read(path);
} catch(error:IOError) {
// нету файла
} catch(error:SecurityError) {
// Нету доступа к файлу.
// тут могут быть варианты, и гораздо больше чем просто нету файла.
// То же отсутствие доступа сложно поверить до открытия файла.
// В таком случае на каждый предполагаемый еррор ставим свой кетч.
// Получится проще и удобнее чем пять ифов подряд.
}

[MikroAcse]

Dukobpa3 , MikroAcse можете привести пример кода, как с помощью try/catch можно написать условие?
А причем тут условие? С помощью try условие не напишешь, просто if и try в некоторых случаях выполняют одну и ту же функцию, поэтому корректнее использовать if.

Вон Dukobpa3 показал прекрасный пример, когда try действительно нужен. Но этот случай не является самым частым, даже достаточно редким.

Видимо на других языках ты никогда не писал..
в джаве без него вообще как без рук
Джава - это джава, actionscript - это actionscript.
В разных языках try работает по-разному, поэтому не стоит тему переводить.

[belv]

Да я это все понимаю, просто тема звучит так "Производительность: try vs if" А по сути это разные вещи, обработка пользовательских ошибок и условный оператор какое между ними VS и скорость работы?
Я бы понял если бы тема была бы "Производительность switch VS if".

[MikroAcse]

belv, свое недовольство будете выражать в ЛС или на другом форуме, а тут все предельно ясно.
Название темы не должно полностью рассказывать о проблеме ТС, так как для этого есть пост/топик.
И, я думаю, проблема ТС уже решена: используй try, когда это действительно нужно.

[belv]

Я не высказываю никакого недовольства
Из кода Dukobpa3, какой код будет работать быстрее при условии, что никаких ошибок не генерируется?

[alexcon314]

if быстрее
try вообще выполнение всего блока тормозит раза так в три.
Содержание второго поста топика у вас вызывает сомнения? Напишите тест. И мы заодно посмотрим.

[caseyryan]

Джава - это джава, actionscript - это actionscript.
В разных языках try работает по-разному, поэтому не стоит тему переводить.
Одинаково он работает, и предназначен для одних и тех же целей. И про 99% случаев - это был явный перебор. Try / catch и в ас3 часто используется, например при сетевом взаимодействии

А вообще, автор мог бы просто замер провести по скорости. Что-то мне подсказывает, что это было бы всяко быстрее, чем создавать тему на форуме
С помощью try условие не напишешь
Что же это в таком случае? Не условие? try / catch / finally - это ткое же условие. Если перевести на человеческий язык "если не срабатывает блок try, перемещаемся в catch. И в любом случае выполняем finally

[belv]

Тест показал, что if выполнялся за 1 мили секунду , а try без генерации ошибок 0 секунд.

var mc = new Mc();
var date = new Date();

var startDate = date.time;
if (mc) {
addChild(mc);
} else {
}
/*try {
addChild(mc);
} catch(error:IOError) {
// нету файла
} catch(error:SecurityError) {

}*/
var endDate = new Date();
trace(endDate.time - startDate);

[Dukobpa3]

Мммм, отличный тест.
Запусти 10 раз подряд и получишь разные результаты.
Это в цикле делать надо, тысяч этак на 10 повторений. А потом суммарное время мерять.
Плюс кетч нормальный вставить, к чему в аддчилде иоЕррор? Там будет эррор ссылки на нулл. Вот его и надо ловить.
Плюс попробуй ему таки нулл скормить пару раз.
Что за тест вообще?

[alexcon314]

Пора в фак записать, как нормально временной тест делать :).
var C:int= 10000000, c:int, t:int, i:int;
t = getTimer();
c = C;
while (c)
{
if (true)
i = 0;
c--;
}
trace(getTimer() - t); //1315
t = getTimer();
c = C;
while (c)
{
try
{
i = 0;
}
catch (e:Error)
{

}
finally
{
c--;
}
}
trace(getTimer() - t); //1701

ну, не в три раза, но помедленнее. Все же не настолько, чтобы от него отказываться в 99% :)

[belv]

А как с if писать?И про finally речь не шла.Ясное дело , что на него время расходуется.

[Dukobpa3]

не в три раза, но помедленнее.
А теперь добавить в 20% случаев попадания в елсе или кетч. Вот там то и будет втрое.

Добавлено через 1 минуту
Как грамотно для этой ситуации тест написать я не знаю, ведь в случаем с ошибкой - придется выкидывать еще ошибку, а это доп-время, тест будет неточным.

[alexcon314]

Речь шла о сравнении в отсутствие ошибок.
belv, что вам еще не понятно? Выкиньте finally, попробуйте без него. Делов то.

[belv]

Так напишите пожалуйста тест для проверки if.Ведь в коде у Dukobpa3, как раз и проходит проверка будет ошибка или нет.

[Dukobpa3]

Да при любых раскладах.
Следует помнить что сравнение - самая быстрая операция ас3.
А в случае с трай-кетч. С трай всё понятно. И то тест показывает что он медленее работает даже без ошибок.
А вот что происходит если мы попадаем в кетч?

Это значит что какой-то кусок системы упоролся полученными даннными, на каком-то этапе обработке. Т.е. часть логики в любом случае выполнилась, время потрачено. После чего мы получаем некую ошибку.
Для того чтобы вылетела ошибка опять же, ее нужно сгенерировать и плюнуть получателю. Опять же время.

Т.е. если мы не отфильтруем данные на предварительном этапе, то заставим систему гонять кривые данные, пока она не наломается на каком-то этапе. И перерасход времени будет тем больше - чем глубже твоя система упорется твоими данными.

Как-то так.

[alexcon314]

belv, или я что-то упустил, или вы не хотите посмотреть внимательно: тест приведен и для if и для try-catch. Допилить его под ваши нужды нетрудно, если все же я что-то упустил.
Dukobpa3, речь шла о сравнении в отсутствие ошибок:). Не более и не менее.

Стоит иметь в виду, просто, что try выполнится всегда, куда мы там попадаем после - это вопрос другой. Тогда как разумно поставленное условие может просто не допустить выполнения ветки с кодом. Собственно, try хорош, когда невозможно разумно такое условие поставить в силу каких-то причин.

[Dukobpa3]

try хорош, когда невозможно разумно такое условие поставить в силу каких-то причин.
Именно:)

[alexcon314]

Ага, а есть еще привсем при том throw. Это я к тому, что можно попасть на либу, в которой методы void, а об ошибках кидают эсепшн, ну, вот спроектировали так. Тут хочешь-не хочешь за try возьмешся :).

[belv]

Да, действительно не досмотрел.Но вот в чем еще вопрос, написал переменную с типом Boolean, которую проверяю в условном операторе и несколько раз скомпилировал тест, то получается то if больше, то try.В пределах 144/152 , 149/140 соответственно.

var C:int= 10000000, c:int, t:int, i:int;
t = getTimer();
c = C;
var b:Boolean = true;
while (c)
{
if (b)
{
i = 0;
}
c--;
}
trace(getTimer() - t);
t = getTimer();
c = C;
while (c)
{
try
{
i = 0;
}
catch (e:Error)
{

}
finally
{
c--;
}
}
trace(getTimer() - t);

[Dukobpa3]

замер таймера с ифом берется ДО того как объявляется буль. А надо после.

[belv]

Да без разницы, те же 144/152 , 149/140

[expl]

if быстрее
try вообще выполнение всего блока тормозит раза так в три.
Как-бы выброс исключения - это исключительная, редкая ситуация.

Вы в метод передаёте фигню, на которую он не может ничё корректного ответить и поэтому кидая исключение надеется, что люди повыше знают побольше и смогут правильно среагировать (обычно тупо более информативную запись в лог добавить)
Т.е. выше могут написать пользователю "Ваши данные побились", а метод максимум обладает информацией, чтобы сказать "индекс вышел за пределы".

Так вот:
- ваше приложение выкидывает исключения
- ваше приложение выкидывает их с частотой 100Гц
- если реже, просто вряд ли вы почуете разницу в производительности
- если не почувствуете - вас вообще не должно беспокоить, что исключения медленно работают
- если у вас в метод 100 раз в секунду передаётся полная лажа - то может быть что-то не так в Консерватории?
- т.е. либо надо чинить приложение, либо перестать использовать аварийную систему для обработки штатных событий.

Но это по логике, а не по логике - в Python, говорят, падать на "index out of range" по окончании итерации - это считается штатным режимом.

[alexcon314]

Кстати, да. if(true) оптимизируется компилятором, видимо. Недоглядел. Так, как у вас более корректно. Примерно одинаковое время тестов говорит, что в споре try vs if в условиях теста, по крайней мере, нет победивших :).

[Frost47rus]

Использовать try/catch как проверку условий - имхо, извращение.

try
{
var object:Object = JSON.parse(string);
}
catch(e:Error)
{
trace('parsed string is not an object');
}

[dimarik]

Ну что, знатоки, на чем остановились? Напомню
Здравствуйте, подскажите, что быстрее работает

try
{
myObject.doSomething();
}
catch(error:Error)
{
}


или


if(myObject)
{
myObject.doSomething();
}

[Dukobpa3]

Не знаю как кто, я остановился на том что сравнение не совсем корректно.
Но если уж сравнивать то сравнение в отстутсвие ошибок либо попадания в елсе - смысла не имеет. И в таком случае монопенисуально.

Но стоит нам добавить несколько процентов попаданий на темную сторону силы, и тут........

[alexcon314]

dimarik, знатоки внемлют :).
Dukobpa3, пробуем генерировать ошибки:

var C:int = 1000000, c:int, t:int, i:int, k:Number = 0.0; // это как бы процент неошибок :)
t = getTimer();
c = C;
while (c)
{
if (c > k * C)
i = 0;
else
i = doSomeThing(false, c, C, k);
c--;
}
trace(getTimer() - t);
t = getTimer();
c = C;
while (c)
{
try
{
i = doSomeThing(true, c, C, k);
}
catch (e:Error)
{
//trace(e.message);
}
finally
{
c--;
}

}
trace(getTimer() - t);

private function doSomeThing(bCrash:Boolean, c:int, C:int, k:Number):int
{
if (bCrash && c > k * C)
{
throw new Error("error");
}
return 0;
}

k -0, if - 192, try -2500
0.5, 315, 1455
0.8, 385, 853
0.9, 385, 653
1.0, 445, 410

Но если уж сравнивать то сравнение в отстутсвие ошибок либо попадания в елсе - смысла не имеет.
Мне не понятно, каким образом может "повредить" if'у попадание в else. Ну, а ошибки, само собой. Только отжирает время скорее не try, а throw.

[Dukobpa3]

"повредить" if'у попадание в else.
Ифу не повредит. Но если уж мы взялись сравнивать с трай-кетчем то для чистоты эксперимента нужен и кетч и елсе.