worklog: Dynamic allocation
а вот помыслим себе оторванную от жизни и практических применений задачу наподобие усреднённого (сказал же - оторванное от жизни, т.е. в постановке задачи присутствует некое абстрактно-туманное предположение от потолка) контроллера, встроенного в некое усреднённое управляющее приложение. Допустим, это новомодный смарт-дом или, например, система управления теплицей или, скажем, всего-то контроллер производственной линии, пекущей хрустящие французские булки.
Сам контроллер принудительно сделан так, чтобы хипстеры под него код писать НЕ МОГЛИ -- ибо сам процесс написания кода требует понимания физических процессов (чего хипстеры лишены в силу органичеких причин), а железо выбрано так, что на нём не запускается виндовс с докерами. Т.е. пишем на Си или чём-то подобном в плане возможностей выстрелить себе в ногу и т.п.
Но при этом памяти, допустим, мегабайты. И есть GUI - пусть без градиентиков и трёхмерной анимации, но с кнопочками и чекбоксами.
Так вот, в задаче спрашивается: каково ориентировочное количество одновременно выделенных фрагментов динамической памяти (т.е. из кучи, а не из стека)? А каково максимальное? ессно, можно предположить типа "миллиарды", но если более реалистично? вот, например, 16 мегов оперативки. Ясное дело, что невозможно будет выделить памяти больше, чем её есть. И фрагментов вряд ли будет больше, чем есть байтов (а на самом деле ещё меньше, так как оверхед) - вот уже прорисовывается верхняя граница. Но она всё равно ещё довольно-таки велика.
Если выбрать слишком малое число, то система будет неработоспособной. Если слишком большое - возможно, будет зряшный расход памяти под некие вспомогательные структуры и её не хватит под нужные данные.
Как найти ещё более реальное значение?
Я вижу такой вариант: заложить какое-то большое, но допустимое значение и погонять рабочий софт в разных (но практически осуществимых) режимах, собирая статистику. Потом, основываясь на этих данных, пересобрать систему. Возможно, с каким-то запасом типа +10%.
Сам контроллер принудительно сделан так, чтобы хипстеры под него код писать НЕ МОГЛИ -- ибо сам процесс написания кода требует понимания физических процессов (чего хипстеры лишены в силу органичеких причин), а железо выбрано так, что на нём не запускается виндовс с докерами. Т.е. пишем на Си или чём-то подобном в плане возможностей выстрелить себе в ногу и т.п.
Но при этом памяти, допустим, мегабайты. И есть GUI - пусть без градиентиков и трёхмерной анимации, но с кнопочками и чекбоксами.
Так вот, в задаче спрашивается: каково ориентировочное количество одновременно выделенных фрагментов динамической памяти (т.е. из кучи, а не из стека)? А каково максимальное? ессно, можно предположить типа "миллиарды", но если более реалистично? вот, например, 16 мегов оперативки. Ясное дело, что невозможно будет выделить памяти больше, чем её есть. И фрагментов вряд ли будет больше, чем есть байтов (а на самом деле ещё меньше, так как оверхед) - вот уже прорисовывается верхняя граница. Но она всё равно ещё довольно-таки велика.
Если выбрать слишком малое число, то система будет неработоспособной. Если слишком большое - возможно, будет зряшный расход памяти под некие вспомогательные структуры и её не хватит под нужные данные.
Как найти ещё более реальное значение?
Я вижу такой вариант: заложить какое-то большое, но допустимое значение и погонять рабочий софт в разных (но практически осуществимых) режимах, собирая статистику. Потом, основываясь на этих данных, пересобрать систему. Возможно, с каким-то запасом типа +10%.