ну яОдно дело - значения ключей, другое дело - список который записан в узле.
Если список длинный (тот, который $lb()), то для взятия N элемента пробегается весь список последовательно. Если это критично то используйте хранение в фиксированном формате, и стройте доступ на $extract. В списке не используются разделители - это тего-организованная структура - в начале каждого элемента списка стоит индикатор сколько места на него отводится.

zxxxxxASDFGHHJKLQWETTYUOPIOPOOP

z-длина списка указателей xxxxx
x-координата начала каждого элемента списка (разделителей нет)

было бы обращение к нужному элементу всегда в 3 счета
независимо от длины списка

почему они так не сделали?

1) В приведенном варианте нет информации о длине элемента. Сколько байт брать?
--- разница между двумя x - этим и следующим (для последего - с общей длиной )

2) Если изменилась длина поля №2, а всего полей N, то сколько указателей понадобится пересчитать если поля предполагается хранить с переменной длиной?
--- в среднем половину - но меняется на порядки реже чем считывается
если это база данных

3) Тегоориентированная структура $lb() имеет преимущество в том, что можно сконкатенировать два списка как последовательность байт и получим новый корректный список.
--- очень на практике редкая операция

4) В списках $lb() присутствует упаковка числовых величин.
--- не нужно паковать - больше мороки

kvasovПравильно ли я понял, что преимущество хранения информации в самих индексах глобала перед списками в качестве значений узла глобала в том, что глобал всегда сортируется по своим индексам и это оптимизирует $Order–выборки, а если ты запечатал инфу в список, то для какой либо оптимизации выборки инфы из списка, которая там уже никак не отсортирована, ты уже должен создавать 1) обьекты 2) и только эти обьекты умеют создавать отдельные индексные файлы, которые позволяют сортировать инфу, хранящуюся в списках?

А индексные файлы – это кусок технологии обьектов, и если ты отказался от обьектов, то забудь и про эти индексные файлы?

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

у нас вся система (уровня 1с-предприятие)
построена на глобалах без обьектов (обьекты не используем в целях
совместимости MSM - CACHE - M3-LITE )
т е сортировать и создавать индексн глобалы можно и без обьектов
списки используем только по $p() - тоже для совместимости
все работает быстро даже на крупных обьектах