Бывает, что программы "мучительно долго закрываются": нажал ты крестик, а она ещё минут несколько шуршит диском и грузит процессор, прежде чем покинуть список процессов. Говорят, при этом аккуратный рантайм объектно-ориентированного языка аккуратно и поочерёдно уничтожает созданные за время работы программы объекты. Аккуратно, методично, с соблюдением всех требуемых в языке формальностей, потому долго. Вот я и задумался на тему оптимизации уничтожения объектов. Создавать-то мы все умеем, а вот уничтожать с наименьшей нагрузкой на процессор?...
1) Ведь можно же, чтобы объект при уничтожении "грохался молча", без каких-то сопутствующих действий кроме собственно освобождения памяти? Мне казалось, что оно по умолчанию так и есть (если для уничтожения не прописано явно каких-то действий), но что-то берут меня сомнения: нет ли в сегодняшних языках/рантаймах каких-то внутренних навесок "обязательных к исполнению при удалении объекта"? И если есть - почему бы не сделать для объекта флаг "можно грохать молча".
1.1) ...ну, или "грохать молча" хотя бы при завершении работы программы (при установленном флаге, ессно - чтобы старые программы не словили каких-нибудь спецэффектов). Программа завершается, ей больше не нужны вообще никакие объекты, а нужные именно для завершения действия она и сама сделает (если будет знать, что объекты грохаются молча).
2) "Куча в куче" или "объект типа куча". Создаем "новую кучу" (саму являющуюуся например объектом), внутри этой кучи создаём нужные нам объекты. Когда надобность в объектах отпала - грохаем кучу целиком, не заглядывая внутрь (и экономя тем самым работу по уничтожению каждого объектика по отдельности). Удобно понятно для чего - насоздавали для временных нужд много временных объектиков, потом грохнули все разом.
3) "Объект можно грохать, если нужно - восстановим". При работе программ создаётся множество "временных" объектов, в принципе нужных, но не необходимых - какие-нибудь индексы, распакованный в память для лучшей скорости отображения jpeg, и подобные вещи, которые вроде и удалять жалко (а главное - непонятно когда), и место занимают, и пересоздаются в случае чего легко. Ввести для таких объектов флаг "можно грохать, для восстановления вызвать вот это". Если менеджер кучи обнаруживает нехватку памяти, и при этом есть давно не используемые объекты с таким флагом - их можно грохнуть, оставив от них только ссылку на процедуру пересоздания объекта. Если программа обращается к такому объекту - менеджер кучи зовёт процедуру пересоздания объекта, и только потом допускает программу до объекта.
3.1) ...как вариант - грохать такой объект без сохранения чего либо, при обращении к объекту программы - сообщать программе что объект мы грохнули, пусть выкручивается как хочет (обходится без него, или создаёт заново).
3.2) ...кстати, для dz phantom, с её (его?) персистентностью, эта проблема (замусоривание кучи объектами, которые не особо-то и нужны, но нет формальных причин для их удаления) может оказаться актуальной.
Интересно, много я сегодня велосипедов наизобретал?...