Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2010-08-22 18:13:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
За программизм
     Сразу предупрежу - я не программист, поэтому могу быть очень сильно не в курсе текущего состояния дел. Но есть мысли, и я их думаю.

     Бывает, что программы "мучительно долго закрываются": нажал ты крестик, а она ещё минут несколько шуршит диском и грузит процессор, прежде чем покинуть список процессов. Говорят, при этом аккуратный рантайм объектно-ориентированного языка аккуратно и поочерёдно уничтожает созданные за время работы программы объекты. Аккуратно, методично, с соблюдением всех требуемых в языке формальностей, потому долго. Вот я и задумался на тему оптимизации уничтожения объектов. Создавать-то мы все умеем, а вот уничтожать с наименьшей нагрузкой на процессор?...

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

     Интересно, много я сегодня велосипедов наизобретал?...


(Читать комментарии) - (Добавить комментарий)


[info]slowkukuing@lj
2010-09-11 23:19 (ссылка)
1. так в джаве сделано (поскольку нет деструкторов). Если нужно что-то таки "деструктить", то объект должен реализовать finalize
1.1. опять же - в джаве exit() отрабатывается "мгновенно". Т.е. считается что все "внешние" ресурсы "аллокируются" через jvm и, соотв., jvm по завершению их вернёт в систему (да ещё и система, на самом деле, "отбирает" ресурсы у убиваемого процесса)

2. видел такое в Obj-C, но ни разу не юзал и не видел, чтобы кто-то юзал.

3. в джаве - Weak/Soft Reference и иже с ними. юзал.
не оч. удобно, поскольку для полноты идеи нужно закрывать доступ непосредственно к объекту через прокси, а прокси в джаве строятся только от интерфейсов (уррроды!)

-+-
реально, как уже ниже (т.е. выше) упомянули, "тормоза" проистекают не от "деструкторов" как таковых, а в силу неких "завершающих" процедур - временные файлы почикать, то-сё в реестре записать/постирать... некоторые проги вообще для своей работы запускают сервисы, которые по выходу пытаются положить и ты.ды.


(Ответить)


(Читать комментарии) -