Вопрос исключительно касательно 1С 8. В связи с тем, что не смог найти каких-либо деталей реализации "примитивных" типов 1С, вопрос к тем, кто данный вопрос исследовал.
Собственно, вопрос:
Какая операция в 1С будет осуществляться эффективнее - СЛОЖЕНИЕ двух объектов типа "Число" или СРАВНЕНИЕ двух объектов типа "Строка" ("Число" ~ [10].[3], "Строка" ~ [20]), при том, что в строке сравнивается один символ на заданной позиции?
Еще раз повторюсь, что смущает именно неизвестность внутренней реализации данных типов. Может у кого-то есть подобная информация, был бы рад получить ссылку, к примеру. Спасибо.

других проблем совсем уже не осталось?

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

напиши два цикла: в первом сложи миллион чисел, во втором — сравни миллион строк.

(1) 3д-шутер пишет.

Я тоже склоняюсь к эксперименту, но думал, может есть какая-то официальная информация от 1С по устройству этих "примитивных" типов.

(5)Не думал что от длины строк и величины чисел может зависеть

(5) ыыы... доступно и всерьез... главное на "" + 2 + 2 = "22" нормально реагировать и не забивать голову вопросами типа (0)

(0) а в чем выражается эффективность этих РАЗНЫХ операций по сути. точнее где сложение двух чисел можно заменить сравнением двух строк

(7) только как из 2+2 получить 22 непонятно

(9) (2+2)*5.5=22

(10) тогда из "2" и "2" и "5.5" получаем "22"? без увеличений количества переменных..

(9) ""+2+2 = 22

(12) равно не будет

(11) а переменные тут хде? СтрЗаменить("2"+"2"+"5.5", "5.5", "")

(14) а почему не СтрЗаменить("2"+"2"+"5.5", "2", ""). по какому критерию был сделан алгоритм работы?

(15) ну мы ж "22" получаем? как ты в (11) просил

Irbis, наверное не зависит, учитывая, что, скорее всего, это сложные объекты.
Одному из алгоритмов поиска простых чисел в заданном диапазоне на С++ понадобилось около секунды, когда "одинэсу" не хватило 14 минут...

Axel2009, алгоритм суммирования по колонкам таблицы. Некоторые числовые столбцы надо складывать, в другие надо по итогам сумм первых записывать средние значения.
Либо суммируем все числовые столбцы (на каждой итерации), а потом затираем некоторые, вписывая в них средние значения, либо вносим признак в имя колонки, по которому в каждой итерации цикла проверяем, участвует ли данная колонка в сложении, или ее пропустить.
Возможно, алгоритм можно усовершенствовать. Прошу предлагать более оптимальные варианты.

Обработать все заранее в запросе , еще до получения первого появления "таблицы".

kosts, таблица - не прямой результат запроса, а результат длительных его преобразований.

(19) Выгрузить ее в запрос и сложить все там.

(19) Может эти преобразования сразу в запросе сделать?

Я в 1С не профессионал, а руководствуясь общей терминологией программирования не понимаю, что значит "выгрузить в запрос".

kosts, может быть, но это, так сказать, "Большей кровью" обойдется :)

(22)


ВЫБРАТЬ
   *    
ПОМЕСТИТЬ ВТВременнаяТаблица
ИЗ
   &Таблица КАК ВременнаяТаблица
;


(23) Зато явно быстрее отработает...
Напиши какие преобразования таблицы были, может тогда я помолчу :-)

(22) позовите специалиста тогда

"таблица - не прямой результат запроса, а результат длительных его преобразований."
"Я в 1С не профессионал, а руководствуясь общей терминологией программирования не понимаю, что значит "выгрузить в запрос"."

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

dmpl, ясно. Только за счет чего после "помещения в запрос" будет ускорение вычислений?

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

ЗлобнийМальчик, если Вы считаете, что подобная задачка уже требует специалиста 1С, то мне жаль "специалистов 1С".

(17) платформа 1C не для этого создавалась

(28) Один вложенный запрос в котором в соединении три регистра накопления. Не?...

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

(28) 1. Практика показывает, что запросами быстрее, и клиент не грузится расчетами.

2. Что за N функций?

(30) Не, тут через ОБЪЕДИНИТЬ ВСЕ надо - во избежание дублирования строк.

Rovan, я понимаю конечно. Но ведь это частный случай операции с числами, не так ли?

kosts, да, но потом кучу колонок еще прицепить надо.

Axel2009, не переживайте, "исправлять" это никто не будет :).

(33) когда ЭТО будет считаться не пару часов, а пару недель, вот тогда придет исправлять. а того кто делал уже нетю, и никто не знает как это работает. в итоге специалист сидит и разбирается в коде, чтобы из ЭТОГО сваять быстрое, которое будет считать пару минут.

dmpl, запросы, насколько я понимаю, выполняются прямо на SQL-сервере, от этого и прирост производительности.
Касательно клиента, вопрос спорный, эти вычисления можно выполнить "НаСервере".
Функции, в большинстве случаев выполняющий запросы, и по их результатам добавляются колонки в общую таблицу.

Axel2009, никто не придет исправлять.

(17) интерпретатор 1С быстротой не отличается - факт известный

Axel2009, 1С - это не Ассемблер, не Си, и даже не VB. "Разбираться в коде" в нем и в полноценном языке программирования - несравнимые задачи.

(35) Ну так в чем проблема выполнять эти запросы прямо в запросе и левым соединением цеплять к существующей таблице? Для удобства эти запросы можно сделать в виде временных таблиц даже если они по 1 разу всего используются.

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

Господин ПЖ, но интерпретатор того же Питона затратил менее 2х минут

(41) интерпретатор 1с выполняет кучу левых подсчетов для каждой операции, чего не делает питон.

Axel2009, но зачем эти операции делать в одном цикле, если об их выполнении никто не просит... Понятно, такая "философия языка", наверное.

(0) пардон, а это взаимозаменяемые операции?

(41) Я компилировать один исходник разными компиляторами C++. Получил разницу в скорости от 5 до 260 у.е.

Кроме того, числа в 1С не с плавающей запятой, так что сопроцессор их не считает. Это, скорее всего, отдельный класс с реализацией различных операций для таких чисел. Т.е., считай, программная эмуляция.

dmpl, да, я тоже так подумал, глядя на допустимые пределы значений типа "Число".

Всем спасибо за участие, попробуем разные подходы.

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

(47) ерундой не майся...

Ветку не читал.

С точки зрения логики - конечно сложение будет быстрее.

Только числа жестко типизируй!

(7) А ты хотел "Ошибку" ? Тебе дали инструмент неявного преобразования типов, а ты ещё нос воротишь!

(50) Жёсткая типизация чисел сильно увеличивает производительность?

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

(47) Правильный подход: сделать 1 большой запрос, на выходе которого получить готовую к употреблению таблицу.

(50) Не факт - строки можно сравнивать по 4 UNICODE символа за такт процессора, а числа с фиксированной запятой - только по 1 цифре за такт складывать(и то только в том случае, если они нормально в памяти лежат, т.е. 1 цифра занимает 4 байта). BDC современные процессоры очень не любят.

А уж к секретным алгоритмам 1С приплетать логику... вообще не стоит. Практика - критерий истины.

(47) экономите на спичках...

(52) На порядки. Готовьте переменные правильно.

   Описание=Новый ОписаниеТипов("Число",Новый КвалификаторыЧисла(15,2));
   РассовоВерноеЧисло=Описание.ПривестиЗначение(0);

(53) Нетипизированных.
Проверяли примерно год назад.

Только типизацию делали не как в (56), а через реквизиты формы.

ТЗ = Новый ТаблицаЗначений;
   ОписаниеТипаЧисло = Новый ОписаниеТипов("Число",Новый КвалификаторыЧисла(15,2));
   ТЗ.Колонки.Добавить("Число1", ОписаниеТипаЧисло);
   ТЗ.Колонки.Добавить("Число2");
   Строка = ТЗ.Добавить();
   Строка.Число2 = 0;
   ТекВр = ТекущаяДата();
   Для Сч = 0 По 1000000 Цикл
       Строка.Число1 = Строка.Число1 + 1;
   КонецЦикла;
   Сообщить("РазницаСекунд = " + Строка(ТекущаяДата() - ТекВр));
   
   ТекВр = ТекущаяДата();
   Для Сч = 0 По 1000000 Цикл
       Строка.Число1 = Строка.Число1 + ОписаниеТипаЧисло.ПривестиЗначение(1);
   КонецЦикла;
   Сообщить("РазницаСекунд = " + Строка(ТекущаяДата() - ТекВр));
   
   ТекВр = ТекущаяДата();
   Для Сч = 0 По 1000000 Цикл
       Строка.Число2 = Строка.Число2 + 1;
   КонецЦикла;
   Сообщить("РазницаСекунд = " + Строка(ТекущаяДата() - ТекВр));


РазницаСекунд (типизировано без привести) = 5
РазницаСекунд (типизировано с привести) = 6
РазницаСекунд (не типизировано) = 4

2 раза запускал, время одно и тоже. что делаю не так?

(58) Счаст померил - действительно нетипизированные быстрее.
wtf?

Счаст поищу ту ветку, повторю те условия.

вот 8.2
РазницаСекунд (типизировано без привести) = 65
РазницаСекунд (типизировано с привести) = 73
РазницаСекунд (не типизировано) = 63
еще все дольше.. хотя вроде замеры делали тогда, в 8.2 веселее работало.. странно =)

ЗЫ нулик добавил к каждому из циклу..

А вот нефиг в потроха "скриптовых языков" лазить, не для того они делались.

(0)
В 8.2 внутреннее хранение числа и работа с числами не менялась еще с 7.7. Кому надо подробностей - смотрите класс CNumeric в исходниках 1С++.
Формат строк немного поменялся, но в-принципе несущественно - как была цепочка нультерминированных символов, так и осталась.

(63) формат ХЗ, а библиотека менялась. От самописки ушли во что-то лицензированное от IBM. в итоге были изменения в сортировке ("и" и "й" вроде считаются одной буквой в некоторых случаях). Значит и производительность могла поменяться довольно сильно.

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