Это не так, как сложность времени работает. Вы не можете делать «простую математику» подобным образом.
Двумерный квадратный массив экстента x имеет n = x*x элементов. Для печати этих n элементов требуется n операций (или n/m, если вы печатаете m элементов за раз), что составляет O(N). Необходимая работа увеличивается линейно с количеством элементов (что, кстати, является квадратичным по отношению к экстенту массива - но если бы вы расположили одинаковое количество элементов в 4-мерном массиве, было бы что-то другое? Очевидно, нет. Это волшебным образом не делает это O(N^4)).
То, для чего вы используете сложность времени, в любом случае не такое. То, что вы хотите, чтобы сложность по времени показала вам, - это приблизительное представление о том, как какой-то конкретный алгоритм может изменить свое поведение, если вы увеличите количество входов за пределы определенного предела.
Итак, что вы хотите знать, так это то, что если вы выполните XYZ для одного миллиона предметов или для двух миллионов предметов, это займет примерно в два раза больше или например, примерно в шестнадцать раз длиннее .
Анализ сложности времени не зависит от «мелких деталей», таких как, сколько времени занимает фактическая операция. Что делает все это более академичным и практически бесполезным в современных архитектурах, потому что постоянные факторы (такие как задержка памяти или задержка шины, ошибки в кеше, сбои, время доступа и т. Д.) Играют все возрастающую роль, поскольку они остаются в основном то же самое в течение десятилетий, в то время как фактическая цена за шаг (пропускная способность команд, мощность ALU и т. д.) неуклонно снижается с каждым новым поколением компьютеров.
На практике довольно часто случается, что тупой, линейный, грубый подход быстрее, чем «лучший» подход с лучшей временной сложностью просто потому, что постоянный фактор доминирует во всем.