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

Если мы про императивные языки говорим

И при деревьях вероятно тоже. Рекурсия у тебя не инлайнится, вызов функции сам по себе дорогой часто. Тело цикла компилятор оптимизирует ты даже не представляешь как. Ифы вообще не проблема — на современных компьютерах они летают, из-за этого от части у тебя enum-dispatch быстрее динамика

Хорошо бы найти бенчмарк. Ладно, буду дальше арбайтен.

Является ли Лукашенко легитимным президентом РБ?

🇧🇾 (1311) T-34 ты задолбал

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

@hirrolot это же завтра будет онлайн митапчик?

да

фух чуть не забыл)

Короче, тут чувак озадачился ручным переписыванием рекурсии в цикл и, внезапно (но я это подозревал!), что эмуляция рекурсии оказалась медленнее.

1.  foo1 is the naive implementation, and also the fastest
2.  foo2 is the manually managed implementation, slightly slower
3.  foo3 is the implementation using futures - very pretty, but slowest

https://github.com/ImmutableBug/recursion_optimization

Дисклеймер: я не запускал бенчмарк, но ревью кода не выявило каких-то ужасных проблем с реализацией, код нормальный. Можно было преаллоцировать Vec во втором случае, но это было бы не совсем честно.

@sirgraim @DogeShibu я бы выбрал (1) как более чистую реализацию.

📌 висит

Да, вроде норм смотрится.

пагадите... чо еще за хешмап

enum StackState {
       Initial(u32, u32),
       FirstRec(u32, u32),
       SecondRec(u32, u32, u32),
       ThirdRec(u32, u32, u32, u32),
   }

макс глубина стека — 4 ? 0_О

Так это не глубина стэка, это возможные состояния того, что может быть на стеке в разные моменты исполнения

Это как раз стандартный подход, когда рекурсию на цикл переписывают

а, точно, уже вижу Vec::with_capacity

я такое только для обхода дерева делал, там было проще со стейтом)

а если 3е сделать на генераторах а не на асинках?