Добрый день, комрады. Интересную штуку заметил сегодня. В оценке производительности вижу 2 строчки:

СчетчикСимволов = СчетчикСимволов + 1;

и

Если МассивСпецСимволов.Найти(ТекущийСимвол) = Неопределено Тогда

Увеличение счетчика символов выполняется 0,000754 с, а поиск в массиве выполняется 0,000023 с. В массиве спецсимволов 9 элементов. Сами цифры малы конечно, но разница то между ними огромная, и при выполнении в цикле на 1000 итераций, сильно заметно. Платформа 8.3.7.1949, замеры проводил несколько раз, для статистики так сказать. Собсна вопрос, почему так то?

Разные операции и разное время выполнение, что не так?

имхо. плавающая арифметика.

(1) о, и правда разные, не увидел сразу. ))
(2) выполняем большой цикл, чтобы усреднить показания. Цикл на 1200 итераций. результат у нас получается:
- добавление единички 0,35 секунды
- поиск в массиве 0,02 секунды.

Просто интересно, неужели добавление единички сложнее в 10 раз, чем поиск в массиве. Мож я единичку добавляю не так, может там с присвоением что-то.

Не забывайте, что платформа чисто прикладная. Может быть всё, что угодно имхо.

сделай счетчик символов реквизитом формы типа число

ну и да - можно весь код?

переменная имеет тип - variant (от сюда не очень большая скорость)
а поиск в массиве оптимизирован...

Тестируем дальше )))
Первый вариант:

...
СчетчикСимволов    = 0;
КоличествоИсходныхСимволов = СтрДлина(ТекстСМС);
Для инд = 1 по КоличествоИсходныхСимволов Цикл
    ТекущийСимвол = Сред(ТекстСМС, инд, 1);
    Если МассивСпецСимволов.Найти(ТекущийСимвол) = Неопределено Тогда
        СчетчикСимволов = СчетчикСимволов + 1;
    Иначе
        СчетчикСимволов = СчетчикСимволов + 2;
    КонецЕсли;
КонецЦикла;
...


Второй вариант:

...
СчетчикСимволов    = СтрДлина(ТекстСМС);
КоличествоИсходныхСимволов = СчетчикСимволов;
Для инд = 1 по КоличествоИсходныхСимволов Цикл
    ТекущийСимвол = Сред(ТекстСМС, инд, 1);
    Если не МассивСпецСимволов.Найти(ТекущийСимвол) = Неопределено Тогда
        СчетчикСимволов = СчетчикСимволов + 1;    
    КонецЕсли;
КонецЦикла;
...


Время выполнения:
1 - 0,51
2 - 0,19

ну и до кучи

все замеры точнее 0.001 сек - это вообще лажа
все замеры точнее 1/17 секунды - довольно приблизительны

(9) согласен, поэтому делаю большое количество выполнений.

(0)Поиск реализован на вставке асм, а присвоение на чистом С++ или вроде того

Как вариант:-)

нестрогая типизация сыграла с плейшнером злую шутку

(11)  близко. поиск в массиве нативный тоесть компилируется , прибавление к произвольной переменной интерпретируется.

(8) что такое "счетчик выполнения?" да и вообще, мой телепат говорит, что найдя любой символ не из ascii надо останавливаться и умножать длину на два.

потому что в sms не utf-8, а utf-16

в таком случае

в (14) "счетчик выполнения?" -> "время выполнения?"

имхо, массив оперирует данными которые уже закешированы в памяти, а счетчик инициализирует изменение своей переменной в буфере.
Я думаю если перед поиском элемента в массиве этот элемент туда вставлять (в смысле замерять еще и эту операцию) - разница будет существенна.

и в данном случае надо организовывать не поиск по массиву,  проверку кода символа Сред(Текст, счетчикцикла, 1) на >127

(19) ваш телепат вас подводит. Написано же, массив спецсимволов. Или вы думаете, что я туда весь алфавит запихал? В данном случае я просто проверяю наличие символов, которые всегда идут за 2, не зависимо от кодировки, например "{", "}", "[", "]". Да и спрашивал я совсем о другом.

(17) время выполнения в секундах, из оценки производительности.

(20) если не трудно, озвучьте задачу полностью, нам же интересно.

(0) замени массив на соответствие - офигеешь

как-то сложно... массив, соответствие

СтрНайти(Символ, "[]{}") > 0

(20) понятно. ну, тогда см. (5)

Поиск в массиве реализован по сути перебором массива. Перепиши свой код, офигеешь от циферь.

(22) задача посчитать, в сколько СМС выйдет отправка сообщения клиенту. Я посимвольно смотрю текст отправки. Если символ попадает в спецсимволы, то его считаем за 2 и тут же смотрим код символа, если хоть один попал выше 127 или символ = "€", то будет аскии.
Потом проверяем общее количество символов, если не превысили 70 или 160, то хорошо. Если превысили, то считаем количество СМС кратно 67 или 153. Как-то так.

(25) что мне даст реквизит формы, и что делать, если формы нет?

(27) А не проще в строке заменить спец символы на "00" или что то в этом роде. А потом просто взять длину строки?

(28) у реквизита указывается его тип и, возможно, при инкременте не будет дополнительных плясок.

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

(30) он вирус пишет, который должен к 1Ске присасываться и рассылать спам из 1С

(28) если нет формы, значит есть объект обработки. если нет объекта обработки и это, допустим, фоновое задание, значит грустим :)
но такие задачи, когда все упирается именно в счетчик - очень редки. Да и оптимизируются они достаточно просто. например в данном случае можно увеличивать счетчик только в случае попадания в массив спецсимволов, а потом прибавлять длину.

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

чаще на большом количестве соединений строк через + при работе с длинными строками проседает

(33) Глупый вывод.

(33) не нужно.

(32) вот это я в (8) и сделал ))

А вообще если код писать в одну строку, то производительность тоже возрастет, а надо ли?

(38) она только в режиме отладки возрастет ;)

Поиск в массиве происходит простым перебором, тк никаких индексов для массива не создается

(35) (36) почему?

(41) Делать математику на 1с глупо. На внешней компоненте можно получить прирост в несколько ПОРЯДКОВ

(42) о какой математике идет речь, не совсем понял.

(41) потому что один запрос к базе или, там, запись объекта, будет в тысячи раз дольше, чем инкремент, даже так реализованный. Соответственно, общая доля во времени выполнения кода будет пренебрежимо мала.

(39) )))) не раскрывай секреты

а вот время доработки, когда надо будет через пол года что-то поменять, будет существенно меньше

(46) это конечно да, соглашусь.

(47) Оптимизировать можно бесконечно, но надо руководствоваться соизмеримостью.

Никогда не забывайте, что
premature optimization is the root of all evil

(49) не, "сначала делаем, потом думаем" и маркетологи - вот от чего всё горе.

(50) Ага,... "Фигак-фигак, и в продакшен"...

(50), (51) маркетологи дааааа, из-за них так и выходит, фигак фигак и в продакшен, потому что все время так: "мы вчера придумали, завтра запускаем!"

(50) (52) Вот так взять и назвать гуру маркетологом...
Это сильно...

(0) "Собсна вопрос, почему так то?" потому что получилось.
Я не знаю как оно там внутри работает, но если оно работает так медленно, то скорее всего там у них какая нибудь дубовая стековая машина на вариантных переменных. Поиск массива выполняется скомпилированым машинным кодом, а сложение выполняется дубовым интерпретатором типа:

сунуть в стек СчетчикСимволов
сунуть в стек 1
сложить
высунуть из стека в СчетчикСимволов

и при каждой операции надо проверять типы операндов, увеличивать счетчики, следить за размером стека и тд. и тп.

Думаю, самое простое объяснение тут - НЕПРАВИЛЬНЫЕ ЗАМЕРЫ. Вот что получилось у меня:
-------------------------
Циклов    1 000 000
Инкремент 0,000702 мсек
Поиск     0,001716 мсек
-------------------------
Для тестирования использовал такой код:
СчетчикСимволов = 0;
    
    МассивСпецСимволов = Новый Массив;
    
    МассивСпецСимволов.Добавить("{");
    МассивСпецСимволов.Добавить("}");
    МассивСпецСимволов.Добавить("[");
    МассивСпецСимволов.Добавить("]");
    МассивСпецСимволов.Добавить("{");
    МассивСпецСимволов.Добавить("}");
    МассивСпецСимволов.Добавить("[");
    МассивСпецСимволов.Добавить("]");
    МассивСпецСимволов.Добавить("{");
    
    Старт = ТочноеТекущееВремя();
    Для ё = 1 По ЧислоЦиклов Цикл
        СчетчикСимволов = СчетчикСимволов + 1;    
    КонецЦикла;
    Время1 = - Старт + ТочноеТекущееВремя();
    
    Старт = ТочноеТекущееВремя();
    Для ё = 1 По ЧислоЦиклов Цикл
    КонецЦикла;
    Время0 = - Старт + ТочноеТекущееВремя();
    
    ТекущийСимвол = "_";
    
    Старт = ТочноеТекущееВремя();
    Для ё = 1 По ЧислоЦиклов Цикл
        Если МассивСпецСимволов.Найти(ТекущийСимвол) = Неопределено Тогда
        КонецЕсли    
    КонецЦикла;
    Время2 = - Старт + ТочноеТекущееВремя();
    
    Сообщить("-------------------------");
    Сообщить("Циклов    " + ЧислоЦиклов);
    Сообщить("Инкремент " + (Время1 - Время0) / ЧислоЦиклов + " мсек");
    Сообщить("Поиск     " + (Время2 - Время0) / ЧислоЦиклов + " мсек");
    Сообщить("-------------------------");

(3) Получилось 1 000 000 инкрементаций - 4 сек. У Вас - 292 сек (на 1 000 000). Счетчик типизирован.

(55)
-------------------------
Циклов    1 000 000
Инкремент 0,207147 мсек
Поиск     0,008307 мсек
-------------------------
а какая платформа?

На локальной машине, 8.2.19.83
-------------------------
Циклов    1 000 000
Инкремент 0,13797 мсек
Поиск     0,004084 мсек
-------------------------

не могу получить я результаты близкие к вашим

(57) 8.2.19.121
(58) Вот обработка http://my-files.ru/x70trg , попробуйте на ней

Циклов    1 000 000
Инкремент 0,000306 мсек
Поиск     0,000914 мсек

1С:Предприятие 8.2 (8.2.19.130)

прикол.

поставил вместо

  Для ё = 1 По ЧислоЦиклов Цикл
        СчетчикСимволов = СчетчикСимволов + 1;    
  КонецЦикла;

такое

  Для ё = 1 По ЧислоЦиклов Цикл
        СчетчикСимволов = ё;    
  КонецЦикла;

скорость выросла почти в 3 раза

Инкремент 0,000123 мсек
Поиск     0,000871 мсек

а теперь попробуй так

  Для ё = 1 По ЧислоЦиклов Цикл
        СчетчикСимволов = 1 + СчетчикСимволов;    
  КонецЦикла;

(63) то же самое, что и

СчетчикСимволов = СчетчикСимволов + 1;

(62) Никакого прикола, в первом варианте у тебя выполняется две операции: сложение и присвоение, а во втором варианте только присвоение. Если все это перевести в машинные команды, то для первого варианта можем получить неожиданно больше команд, чем для первого.

(65) да знаю я

(66) А чё тогда удивляешься? :)

(64)
мне кажется, что 1с пытается сначала вызвать деструктор для варианта а потом вызвать конструктор для нового типа.

0.1 мсек для 1 млн операций - о какой оптимизации может быть речь.
Если только о теоретической

(67) да просто
(68) и нафига там деструкторы с конструкторами? чо-то умное хотел сказать чтоли? :)

я вот занимался когда то интерпретаторами. из моих поделок самый медленный работал с такой же скоростью как и 1с. Он тупо читал команды и гонял на стеке варианты. я вот и подозреваю, что одинесовский работает по такому же принципу.
дешево, удобно и практично.

Вот байткод 1С для двух вариантов:

//СчетчикСимволов = СчетчикСимволов + 1;
PushLocal    СчетчикСимволов
PushLocal    СчетчикСимволов
PushConst    1
Add
Assign

//Если МассивСпецСимволов.Найти(ТекущийСимвол) = Неопределено Тогда КонецЕсли
PushLocal    МассивСпецСимволов
PushLocal    ТекущийСимвол
SetParamsCount    1
CallObjectFunction    9
PushReturn
PushUndefined
EQ
JZ    174
Jmp    174
174:

А как это выполняется внутри интерпретатора - 1С только знает.