Antonariy marvanВариант 2 выполняется за 0.08 сек

А можно это оформить в виде функции? А то у меня вместо нужной строки хрень какая-то получается.
Типа так:


"Это" (конкатенацию пары строк) практически абсолютно бессмысленно оформлять в виде функции.
(Если у тебя проблема с конкретным кодом - лучше опиши, в чем она, чем тратить время на такую функцию.)

Написать функцию эффективней того, что ты сам только что написал почти
нелья. Почти в том смысле, что в pCod-e любая функция будет заведомо
давать проигрыш по сравнению с инлайн-соединением, в компилированном
коде "могут быть варианты", но они заведомо не стоят по достигнутому
результату приложенных услий, и абсолютно не оправдают ожиданий.
Причины этого будут изложены ниже.

"Это" (циклические соединения строк) чаще принято оформлять в виде классов, набирающих строки и отдающих их
"за раз".
Самая короткая, простая, но достаточно эффективная и красивая
своей краткостью реализация из тех, что доводилось видеть - принадлежит
Андрею Митину:
http://am.rusimport.ru/MsAccess/topic.aspx?ID=261

вот тут чуть сложнее
http://www.vbaccelerator.com/home/VB/Code/Techniques/StringBuilder/String_Builder_Class_and_Demonstration_zip_cStringBuilder_cls.asp

Вообще, если полазить по интернету, то с пяток относительно различных реализаций для VB4|5|6 наберется.

Все они (как и приведенный 12 фев 04, 16:47 код от marvan ) так или иначе
используют одни и те же принципы работы со строками, понимание которых
складывается примерно таким набором:

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

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

Для VB/VBA выделение строк (как и для всех остальных "потребителей в системе", обращающихся к COM за получением строк) производят функции из
OleAut32.dll. В отношении строк - это общесистемное узкое горло. В многозадачном окружении запросы на памать для строк COM отрабатывает последовательно. (Это значит, что если есть несколько VB-Like приложений,
очень активно работающих со строками, то они, являсь прямыми
конкурентами за общий, но последовательно раздаваемый ресурс, только по
одной этой причине вместе отработают гарантированно за большее время
(простаивая в очереди на обслуживание), чем сумма времен их "монопольной
работы".) Строки - это в целом дорого. (Впрочем, как и динамические массивы).
Длинные строки выделяются из общесистемной кучи. В нагруженной "активно-строковой" ситуации, при интенсивном обращении за новыми (все более длинными) строками (и не освобождении ранее занятой памяти) "строковое пространство" (может) быстро дефрагментируется и все заканчивается сообщением об ошибке - "память для строк исчерпана. Каюк."
(И, чем ближе к этому "каюк", тем медленней начинает отзыватся система, аккуратно выискивая - есть ли у нее еще или уже нет, возможность выполнить запрос на выделение памяти. Особенно, когда строко-пожирательных задач в системе оказывается "много".)

Короткие строки (по возможности) выделяются из внутреннего кеша в 64К, размещаемого в недрах OleAut32.dll.
Если там еще осталось место, не занятое другими короткими строками и строки-операнды "уже там", а строка результат способна разместиться в этом оставшемся месте в виде непрерывного диапазона - значит вам настало шчастье и опреация сложения строк выполнится так быстро, как это вообще возможно в COM.
Такое сложение "самооптимально" и по скорости его по существу - "нельзя улучшить".

Из всего вышесказанного выводятся следующие самые общие рекомендации по работе со строками.
- myStr = vbNullString - это вполне приличный тон, когда вам больше не нужно ранее заказанное строковое пространство. На мой взгляд, для коротких это в целом важнее, чем для длинных.
- За выделением длинных строк следует обращаться настолько редко,
насколько это вообще возможно по смыслу конкретной задачи и/или универсальности применения разрабатываемого класса (или функции, содержащей в себе цикл накопления строки). Стандартный способ - запросить (строку) с большим или меньшим запасом и потом "вписывать в запрошенное", а не "складывать".

В целом эта техника и обсуждалась ранее в данном потоке.
Чем реже обращения, тем быстрее не только ваш алгоритм, но, по ходу дела, еще и общая лохматость, пардон, "строковая мультизадачность" повысится.
Несколько другая техника может быть сформулирована так - складывай короткое образовывая среднее (часто). Складывай среднее среднее, образовываяч длинное. Длинное старайся не складывать, а если придется - то длинное складывай с длинным.

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

ЗЫ
за многословие - извинения с выражением.
Но зато нажмакался.
:)