Есть ли смысл в настоящее время (середина 2020-х) создавать алгоритмы, которые экономят память в ущерб времени?

Актуально ли это? Речь не идет об O(n³) памяти - только в пределах до O(n) с не слишком большими коэффициентами. Речь также не идет о нишевых алгоритмах в стиле решета Аткина. Речь также не идет о старых ноутбуках, на которых можно ждать несколько часов, зато не вылетит из-за недостатка памяти. Речь также не идет о расходах огромного количества памяти впустую - именно о типичной ситуации, когда экономия времени увеличивает расходы памяти, и наоборот. Речь идет об обычных, повседневных приложениях, таких как браузер, офис, архиватор, IDE с любимыми языками (у нас же тут форум программистов? - для них IDE - повседневность?) В одной из предыдущих моих тем мне написали, потребляют ли методы моей библиотеки много памяти, и я так понял, что это кому-то показалось плохо. Насколько я знаю, в последние десятилетия объемы памяти растут намного быстрее, чем тактовая частота процессоров, и даже если кому-то не хватит "чистой" оперативной памяти, у большинства сейчас большие и быстрые NVMe SSD, на которых всегда можно расширить количество памяти. И насколько я понимаю, время ожидания для большинства важнее, чем несколько гигабайт ОЗУ/подкачки. Предлагаю обсудить.

0

Сообщение от Etyuhibosecyu Но 1 - невозможно "за один прием" покрыть юнит-тестами сразу всю библиотеку, это делается медленно и постепенно

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

0

Сообщение от Катафалк И нормальными разработчиками это делается параллельно разработке.

Для всех новых методов в Corlib.NStar я так и делаю. А что делать с методами, которые были с самого начала не покрыты тестами? Я постепенно покрываю их юнит-тестами, но, как я уже написал, это не быстро.

0

Сообщение от Etyuhibosecyu А что делать с методами, которые были с самого начала не покрыты тестами?

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

0