Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>До выполнения точки Т1 мы должны выделить
ЭФ>А+Б+В+Г+Д(количество вызовов других функций)*размер указателя на блок для функции
ЭФ>единиц памяти.
ЭФ>Там же мы должны создать сразу блоки под каждую из других функций.
Цикл может ни разу не выполниться, но вам придется все равно выделить для него память (В+Г+Д и пр.) и это касается не только циклов, придется заранее выделять максимальный размер фрейма из возможных или двигать его в куче, что будет очень медленно.

ЭФ>Но не выделяем пока память под блоки для функций, вызываемых глубже (вассал моего вассала не мой вассал).
ЭФ>То есть, память выделяем не всю сразу, а на одно углубление по стеку.
Ну и работать такая оптимизация тоже будет только на одно углубление, т.е. для вызовов из тела цикла, а для функций вызывыемых глубже проблема остается.

ЭФ>Т.е. под функцию main выделяем блок, размер которого определяется переменными, которые использует main и размерами стеков функций,
ЭФ>которые main вызывает непосредственно.
В некоторых случаях память в стеке можно заранее не выделять, а выделить только когда потребуется, как здесь:

if (...) {
  int a[1024]; // <--
  //...
  return;
}

а вам придется заранее резервировать память даже если условие не выполнится или переаллоцировать фрейм в куче.

ЭФ>> И, даже, наверное не по циклы влияют, а ветвления. Надо ещё подумать.
C> если условие

Вот, у меня как раз новая идея. Выделять на условиях.

Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мы решали проблему "плотных циклов". И решили.
Нет — я же вам показал. По-прежнему будет перевыделение фреймов.

ЭФ>>Мы решали проблему "плотных циклов". И решили.
S>Нет — я же вам показал. По-прежнему будет перевыделение фреймов.

Но не во всех циклах, а только "в высоких". А в "плотных" — не будет.

Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но не во всех циклах, а только "в высоких". А в "плотных" — не будет.
Вы ищете ключи под фонарём. Ну заточили вы работу под один пример. Та же рекурсия по дереву будет приводить к постоянным перевыделениям, просто вместо O(N) выделений вы получите O(N)/const. Я же говорю — подобные идеи приходили в голову разработчикам. Во всех областях, сколь-нибудь чувствительных к производительности, их пришлось закопать за непригодность.

S> вместо O(N) выделений вы получите O(N)/const

А при переходе от стека к куче сложность получится O(N)*const₂.
По вашей логике на этот незначительный факт тоже можно не обращать внимания.

Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>А при переходе от стека к куче сложность получится O(N)*const₂.
ЭФ>По вашей логике на этот незначительный факт тоже можно не обращать внимания.
Брр. Вы сейчас что с чем сравниваете? Понимаете, затраты на выделение в случае нормального аппаратного стека равны примерно нулю. А вы сравниваете их с O(N), где N — это полное количество итераций самого внутреннего цикла.