Что быстрее Таблица значений с индексом или Соотвестствие?

различия не обладают статистической достоверностью - проверено экспериментально года 3 назад на разных объемах

я отдаю предпочтение соответствию в виду более простого и понятного синтаксиса.

Если Кэш[Значение] = Неопределено тогда

проще, чем

Если Кэш.НайтиСтроку(Значение, Колонка) = Неопределено Тогда


меньше букв, больше толку

Получения данных или поиска по ключу?

(3) поиск по ключу

по логике Соотвествие должно иметь порядок O(1), а таблицазначений с индексом O(log(N))
В свое время тестировал СписокЗначений там O(N^1.2)

(0) тебе ехать или шашечки?

(4)
Соответствие не может иметь O(1) - такое только у доступа в массиве по индексу.
Скорее всего (не могу ручаться точно) - Соответствие основано на хэш-таблицах, а индекс в ТЗ на деревьях.

соответствие быстрее

соответствие быстрее для примитивных типов

Когда-то давно баловался
https://www.screencast.com/t/g9KqPYIXjg
не помню уже, чем наполнял с точки зрения типов данных

(6)вся суть хеша как раз в том и есть, что доступ к хеш-таблице это константа - О(1)
https://ru.m.wikipedia.org/wiki/Хеш-таблица
Свойства хеш-таблицы
Важное свойство хеш-таблиц состоит в том, что, при некоторых разумных допущениях, все три операции (поиск, вставка, удаление элементов) в среднем выполняются за время O(1). Но при этом не гарантируется, что время выполнения отдельной операции мало?. Это связано с тем, что при достижении некоторого значения коэффициента заполнения необходимо осуществлять перестройку индекса хеш-таблицы: увеличить значение размера массива H и заново добавить в пустую хеш-таблицу все пары.

Нафига гадать, если можно просто попробовать. Все равно неизвестно, как оно в 1с внутри работает. Может оно внутри одинаково абсолютно.

Хэш еще как бы почитать тоже нужно и на это тоже тратится время.

(10)
Всё верно написали. Я то имел ввиду, что О(1) ГАРАНТИРОВАНО даёт только доступ к массиву по индексу. С хешем это не гарантировано и в худшем случае может достигнуть O(N) - если все ключи попали в один букет. На практике несколько коллизий всегда бывает.

(13) Это из разряда что быстрая сортировка это не О(N ln N), а в худшем случае это квадрат?
В алгоритмике, если не указано иное - пишут среднюю сложность алгоритма, а если речь идет о худшем случае, то это обговаривается отдельно.
Операция с хеш-таблицей О(1), быстрая сортировка О большое от N логарифмов.
А в худшем случае случае операция с хеш-таблицей О(N), быстрая сортировка О(N*N)
В (4) все написано верно, в (6) - неверно.

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

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

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

(17) Максимальное - О(N) при добавлении элемента (add) при расширении таблицы. Так как это происходит раз в N операций добавления, на сложность алгоритма "в среднем" это не влияет. вероятность О(N) в остальных случаях исчезающе мала.
Количество проб "в среднем" в случае возникновения коллизии не зависит от размера таблицы.

Поэтому сложность операций по Хеш-таблице "в среднем" равна О(1).

Еще немного информации о реализации Hashtable в .Net
http://www.cyberguru.ru/microsoft-net/net-framework/dotnet-structures-analysis2-page8.html

(18) Так что быстрее, ТЗ или соответствие?

(18) если алгоритмы где теоретически возможно зацикливание

F=hash(S)

Если не найден, то F=hash(S+F)

атака на такое не найдена, но теоритически он имеет сложность бесконечность.
Все современные алгоритмы лишены данной проблемы.
Древние тоже были лишёны.

(19) соотвествие

(20) Зацикливание чего?!
Даже если у тебя хеш-функция всегда выдает одно значение - сложность О(N)
У тебя весь список хранится в одной ячейке.