Имя: Пароль:
1C
1С v8
НеРавно или Не Равно
0 Мандалай
 
18.07.18
18:15
Добрый день.
Озадачился тут вопросом, информации на ИТС не нашел, постю сюда.
Что быстрее будет отрабатывать:
НЕ Х = 0;
ИЛИ
Х <> 0;
?
1 Aleksey
 
18.07.18
18:16
первое
2 Радим1987
 
18.07.18
18:17
3 Мандалай
 
18.07.18
18:17
(1)Теоретические выкладки, документация, практика/тесты или мне так кажется?
4 Aleksey
 
18.07.18
18:20
(3) тогда второе
5 Aleksey
 
18.07.18
18:21
вроде как лет 5 назад на мисте ктото проводил тесты

А в чем проблема накидать цикл на 100500 итераций и сравнить?
6 Tonik992
 
18.07.18
18:21
Я считаю, что второе, т.к. в первом случае 2 операции (НЕ и =)
7 uno-group
 
18.07.18
18:24
Если х=0 тогда
Иначе
.....
ИМХО быстрее будет
8 PR
 
18.07.18
18:30
(0) А какая разница, если делать все-равно нужно вариант 2?
9 Мандалай
 
18.07.18
18:36
Я помню кто-то уже поднимал этот вопрос и если мне не изменяет память, то пришли к выводу, что быстрее работает именно первый вариант, но я могу ошибаться.
Поскольку в первом случае первой операцией выполняется операция сравнения на равенство с конкретным значением, а затем полученному значению присваивается отрицание.
А во втором случае выполняется операция сравнения со всем подмножеством вероятных значений. Если подмножество небольшое, то сравнение пройдет быстро, а если вероятных значений много, то на выполнение операции уйдет много ресурсов.
Но в первом случае, насколько я понимаю, выполняется операция присваивания - НЕ, а она насколько я знаю выполняется медленнее, чем операция сравнения.
Поправьте меня, если я в чем-то ошибаюсь.
10 Вафель
 
18.07.18
18:38
(9) вроде бы при сравнении 1с не приводт типы. какие тогда множества?
11 lodger
 
18.07.18
18:52
(9) "сравнения со всем подмножеством вероятных значений" - это что за синхрофазатрон в простых булевых операциях?
12 Гость из Мариуполя
 
гуру
18.07.18
19:40
а давай прикинем, что X изначально имеет значение  true
13 Zhuravlik
 
18.07.18
19:48
(8) +1, имхо - так читабельнее. Технически хз.
Но есть ли смысл вообще такие копейки считать? Оптимизировать надо обработку данных - запросы / алгоритмы.
14 VladZ
 
18.07.18
20:40
(0) Вариант "НЕ Х = 0" читается хуже. В плане оптимизации скажу так: до таких мелочей стоит докапываться в случае когда весь остальной код идеален по читабельности и быстродействию.
15 kittystark
 
18.07.18
21:32
пару-тройку лет назад здесь уже был холивар на эту тему...
16 Малыш Джон
 
18.07.18
21:53
насколько я помню, на низком уровне происходит вычитание, но результат никуда не сохраняется, а просто смотрятся значения флагов, и на уровне интерпретатора 1С даже в страшном сне не произойдет мутация в эти ужасы с вариациями и множествами.
Чисто формально, НЕ Х=0 - это две логических операции(вычитание и инверсия), Х<>0 - одна, но... это на полном серьезе обсуждается?? разница в быстродействии этих операций в контексте 1С?
Тогда можно и влияние цвета шрифта, которым код написан, на быстродействие обсудить. Лично я - считаю, что da redz goez fasta!
17 vde69
 
18.07.18
21:58
Х<>0

вроде более устойчивая конструкция в плане возможности получить ошибку "нельзя сравнивать типы ...."
18 Сияющий в темноте
 
18.07.18
22:46
Начнем с того,что х будет приводиться к числу как в случае равенства,так и не равенства.
Для языков низкого уровня такое сравнение,это операция Test с установкой флага результата,и любой даже немного оптимизирующий компиллятор сьест ваше не и заменит флаги.
нужно,конечно,смотреть скомпиллированный код 1с,но есть подозрение,что и он умееи сьедать не из за чего первая операция может показаться быстрее.
19 vi0
 
19.07.18
03:59
(0) Х <> 0 - это проще воспринимается, особенно с реальной длинной имен переменных, пока дойдешь до знака сравнения, уже забудешь что в начале НЕ стоит
20 Мандалай
 
19.07.18
09:01
Я привел Х к числу для примера.
Меня в принципе интересует скорость выполнения = и <> с любыми типами значений. Кстати вот в запросах и в алгоритмическом языке разница все таки имеется. Ведь по сути в языке запросов исполнение в клиент серверном варианте передается на сервер, а следовательно операцию исполняет SQL. Что там происходит это видимо уже другая история.
(12)Я так понимаю, Вы клоните к тому, что Х может быть в принципе другого типа? А тут совсем другое что-то произойдет?
Тесты кстати показали, что <> работает быстрее на 5-10 %. Тесты проводились в клиент серверной базе
(14)Соглашусь, но готов пожертвовать удобством в пользу скорости.
(16)Крутые пацаны даже моник протирают перед запуском отчета.
(18)Это что-то сильно умное. Можно сцылку для рожденного 1сом.
21 Сияющий в темноте
 
19.07.18
13:59
И вообще,ключевое,это сравнение именно с нулем,т.к.во первых,один операнд сравнения задан,а во вторых,он имеет очень специальнон значение.
на языке ассемблера для значения,находящегося в регисте аккумулятора обычно есть флаг z,который ставится в единицу,пока число ноль.

просто,в языках высокого уровня обычно переменные в регистр не помещаются,тае как есть в переменной хранится тип значения и само значение.
строгое сравнение сначала проверяет тип,а потом проверяет значение,но в строгом сравнении число 1 целое не равно числу 1 дробному,поэтому,его не используют
обычное сравнение сравнивает типы значений,если типы совпадают,то сравниваются значения,если типы не совпадают,то система проверяет таблицу приведения типов,чтобы понять,какой из типов можно привести к другому или оба типа к третьему,после приведения уже выполняется сравнение значений.если приведение типов невозможно,то получается не равно.
в разных языках программирования по разному решаются ситуации,когда строка,содержащая число,сравнивается с числом,но в 1с будет не равно.
22 dezss
 
19.07.18
14:07
(18) (21) вот согласен...все зависит от компилятора-интерпретатора...
он вообще 2-ю конструкцию логически может заменить на первую...
23 singlych
 
19.07.18
14:12
Помню как-то xmlка правил обмена не читалась, потому что в обработчиках было "<>". 1Ска думала, что это такой тэг...