из того, что вы сообщаете по числам, выглядит так, ч то у вас "зависимость от 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, пожалуй, присоединюсь.
Как минимум, вы получите другой уровень отладки.