Когда эта фича появилась (в 2007.1), где-то попадался совет "если не будете пользоваться, лучше не включайте, т.к. меняется схема распределения памяти процесса и от этого падает быстродействие". Сейчас (в 2010.2) поиском "Long Strings" в документации ничего подобного не нашел. Возможно, это связано с увеличением производительности работы с локальными переменными. Кстати, последнее кто-нибудь тестил?

servit, Ваш поиск был успешнее :)
ИМХО, более интересен другой вопрос: стОит ли использовать длинные строки в тех случаях, когда задача решается иным способом? Дает ли это ускорение, и в каких случаях? Сама ISC пока не особенно активно их использует... но может быть у кого-то уже есть первый опыт?

ValeriuНапример в GT.M начиная по моему с 5 версии, они вообще
вклинили стандартно 1 МгБ Если не ошибаюсь, в GT.M длинные строки допустимы только в локальных переменных, но не в глобалах. Это связано со структурой БД: записи в блоках не могут пересекать их границ, а делать блоки длиннее 32Кб неоптимально с т.з. производительности.
В Cache структура БД более гибкая, поэтому длинные строки (до 3.6Гб) если уж допустимы, то везде.

Блок А.Н.работа с длинными строками будет неоптимальнойСлегка потестив в 2010.2 на таких операциях, таких как $listbuild(), $listfind(последнего элемента списка), $list(вставка элемента в случайную позицию), могу сказать, что скорость на строках до 1Гб вполне адекватна, ее зависимость от длины строки близка к линейной.

Конечно, всюду следует читать "Мб".

Блок А.Н., я всего-навсего хотел сказать, что по первым ощущениям длинные строки (по меньшей мере, до 1Мб), ведут себя аналогично обычным строкам. Дальнейшее уже зависит от задачи и алгоритма ее решения. Если выбран алгоритм O(n**2), то таки да, он таким же и останется.
Тот же список можно последовательно обработать с помощью $listget (O(n**2)) или с помощью $listnext (O(n)).