Так как у вас три вложенных цикла, то, по порядку, число выполнений N2 растет с ростом d как d^3=d*d*d
В точных значениях цикл первого уровня выполнится (d-1) раз, второго d/2 и третьего - тоже d/2

То есть общее число вызовов k процедуры N2 определяется так k = (d*d*d)/8 - (d*d)/4

Для d = 40 k = 7600, обозначим время работы этого случая за t
тогда для d = 252 k = 1984500, значит в таком случае код будет выполнятся за время 261*t

это ответ на вопрос
user-77Как может число предела цикла d как-то повлиять на функцию N2
При условии, что время работы N2 не зависит от "номера вызова" , общее время работы программы здесь определяется числом вызовов N2,
а это число вызовов пропорционально кубу d.
Вот и всё. Это ребенок лет 8 обязан понимать.

booby,

пардон, соврамши число вызовов = d^3/4 - d^2/2
для d = 40 k = 15680, время = t
для d = 252 k = 3988051 время= 251*t

порядка роста это не меняет.

user-77,

главное состоит в том, что во втором случае число вызовов N2 в 251 раз больше, чем в первом.
Это значит, что программа во втором случае должна работать как минимум в 251 раз дольше, если только работа N2 стабильно не ускоряется, волшебным образом, с увеличением значения d, да так, чтобы кубический рост числа вызовов оказался скомпенсированным.

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

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

Для грубой оценки времени точные формулы не нужны.
при квадратичной зависимости следующие 25% процентов потребуют в 4 раза большего времени, а при кубической - в 8 раз большего.
Если, например, окажется, что зависимость кубическая, то после обработки первых 25% вы, за то же время, за которое обработались первые 25% получите в восемь раз меньшую длину продвижения - то есть, около 3.5%., а при квадратичной в 4 раза меньшую - около 6%.

из того, что вы сообщаете по числам, выглядит так, ч то у вас "зависимость от d", вероятно выше, чем d^3, может быть даже d^5.
Совсем плохо может оказываться, когда временные зависимости выше фиксированной степени d, что нибудь сорта d^d.
...
Что-то про свои алгоритмы в частности, и алгоритмы вообще, полезно знать.

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

стоп-стоп.
Прежде всего, вы должны довести себя до состояния, когда глядя на пример


вы на автомате говорите: "О! Это кубическая зависимость времени выполнения от d"

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

Это правда, что не для всякого кода вообще выводятся точные формулы.
Но приближенные оценки можно получить в большинстве случаев.
И, экспериментальный подход, не видя кода, просто методом систематических замеров,
тоже позволит получить вам оценку, характер зависимости времени выполнения от размера задачи.
Для решения вопроса о том, на сколько дней можно уходить спать, этого должно быть достаточно.

user-77,

в том, что вы сейчас пишите - нет смысла.

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

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

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

Возьмем ваш пример и перепишем так:


В таком примере зависимость между изменением значения d и количеством вызовов N2 линейна.
Если d = 10, то общее число вызовов N2 = 50 - по пять на каждом шаге из 10.
Если вы увеличите d с 10 до 20 (на 10) то количество вызовов N2 увеличится до 100, то есть - на 50.
И так, на пятьдесят оно будет увеличиваться при любом изменении счетчика на 10.
Не имеет значения, с какого числа начинать увеличение, - с 10, 120, или 255.

Вот другой цикл


Пусть d = 10.
Тогда цикл по x будет содержать 10 шагов, на каждом из которых будет запускаться в работу цикл по y, тоже состоящий из 10 шагов.
Общее число обращений к N2 окажется 10*10 = 100
То есть, по отношение к d, в среднем, на каждое из его 10 значений процедура будет вызвана 10 раз.
Увеличим d на 10 - c 10 до 20.
Тогда цикл верхнего уровня окажется состоящий из 20 шагов и вложенный тоже из 20.
Но вложенный работает на каждом шаге внешнего, поэтому общее число вызовов N2 станет 20*20=400
То есть в расчете на одно из 20 значений d число вызовов N2 увеличится и окажется уже не 10, а 400/20 = 20
Мы помним, что при d=10 вычислений было 100, при d=20 стало 400, то есть увеличение d на 10 с 10 до 20 добавило 300 дополнительных вызовов N2 к тем 100, которые были при d=10
Увеличим d еще на 10 - с 20 - до 30.
На каждом из 30 шагов внешнего цикла будет 30 раз вызываться N2 благодаря внутреннему циклу.
Всего вызовов получится 30*30=900, увеличение значения счетчика в на следующие 10 дало уже добавление не 300 новых вызовов, а 900-400 = 500
Построим таблицу:
d число вызовов N2 дельта к предыдущему1110100 992040030030900500

То есть, количество добавляющихся вычислений при увеличении счетчика на 10 оказывается зависимым от того значения d,
к которому происходит добавление. Это и называют нелинейной зависимостью.
В данном случае зависимость квадратична, поскольку общее число вызовов N2 определяется величиной d^2
Добавление каждого следующего цикла вложенного уровня в такой схеме добавляет степень к зависимости скорости роста числа
вычислений от d.
В вашем исходном примере циклы второго и третьего этажа выполняются переменное число раз, зависимое от текущего значения индекса предыдущего уровня, но в среднем d/2 раз на втором уровне и d/2 раз на третьем.
Это не меняет характер роста - он остается как d^3 по порядку величины.

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

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

Правильно ли я вас понял, что в вашем вопросе с самого начала не было смысла, и вы заранее знали на него ответ?

если бы с самого начала разговаривали в терминах своей реальной задачи и показывали код, было бы яснее, можно ли,
и что именно, сделать для общего ускорения/понижения степени зависимости от "размера задачи".
У меня сохраняется подозрение, что ваша N2 имеет свою степень такой зависимости выше 1.

Зачем вам это?

Все хорошо со строками.
Если длина склеиваемых строк зависит от d, то просто, при неумелом использовании склейки, добавится еще та степень к зависимости
времени выполнения от d, в какой в среднем растут склеиваемые строки в зависимости от d.

Когда степень превышает 2, очень быстро становится неинтересно, какая она на самом деле - 3 или 5 или 8.

это слишком абстрактная постановка вопроса.
Может быть - какая-то комбинация из перечисленного.

про сложение строк - поищите, на форуме или рядом, в районе 2003-2005 годов должно найтись много разных быстрострокодобавляторов.
Какие-то из них должны легко переноситься на vbs, какие-то нет.

как вариант:
https://www.sql.ru/forum/73509/optimizaciya-raboty-so-strokami

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

И да, к совету про перенос работы в Excel, пожалуй, присоединюсь.
Как минимум, вы получите другой уровень отладки.

Примерно полтора порядка у вас еще остаётся в запасе на разного рода эксперименты, это можно сказать наверняка.
Но психологического эффекта такой силы вы, конечно, уже не получите.

Вы себя вообще нормальным человеком считаете?
В каком таком "данном", если вы никакого случая не дали?

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

Ну, в размерах десятков килобайт на массив - почти несомненно, возможно даже до приличного количества мегабайт, если повезет.
Говоря сильно грубо, он позволяет при работе с массивом использовать "экономные" подходы к выделению памяти,
отдалённо того же рода, которые используются при работе с "короткими строками", которые вы упоминали.
А про его содержательное назначение прилично было бы и в справке почитать, хотя бы по vba.