понедельник, 10 ноября 2014 г.

Коротко. Чем собственные зомби-объекты для меня лично лучше, чем FastMM

Сама проблема поставлена тут - Об объектах-зомби и борьбе с ними

И вот в комментариях было написано (http://programmingmindstream.blogspot.ru/2014/11/blog-post_8.html?showComment=1415487831879#c6290262245505678584):

"Да, и ещё... FastMM4 в FullDebugMode достаточно уверенно ловит повторное освобождение объектов."

Несмотря на то, что в исходном посте я написал - "Сразу оговорюсь - я знаю про FastMem".

Что хочу сказать?

Чем лично для меня собственное решение "на коленке" - лучше?

Тем, что FastMM требует режима FullDebugMode , который "не так лёгок" (ну или я не умею его готовить) и выдавать всем пользователям подобное приложение - накладно. Оно будет "мешать им работать". Да и зачастую всем - и не нужно.

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

А вот "собственный" менеджер памяти можно включить/выключить практически "на лету", например меняя флаг в ini-файле или вообще по срабатыванию какого-нибудь триггера в бизнес-логике.

Вот собственно и всё. Универсальное решение - оно конечно хорошо. Но зато не универсальное решение поддаётся более тонкой настройке в конкретных условиях.

Ну и собственно - зная про"мой менеджер памяти" можно "примерно представить" - как устроен FastMM.

Что - зачастую - полезно. "Назад к основам" так сказать.

Ну и кстати ещё из "серии работы с памятью" - Коротко. Об оптимизации потребления памяти под xCode. Затравочка.

7 комментариев:

  1. «...Тем, что FastMM требует режима  FullDebugMode  , который "не так лёгок" (ну или я не умею его готовить) и выдавать всем пользователям подобное приложение - накладно. Оно будет "мешать им работать". За и зачастую всем - и не нужно.»
    -- См. FastMM4Options.inc:
    «{Combines the FullDebugMode, LoadDebugDLLDynamically and
    DoNotInstallIfDLLMissing options. Consequently FastMM will only be installed
    (In FullDebugMode) when the FastMM_FullDebugMode.dll file is available. This
    is useful when the same executable will be distributed for both debugging as
    well as deployment.}
    {.$define FullDebugModeWhenDLLAvailable}»

    -- позволяет включать FullDebugMode только в случае наличия в пределах доступности FASTMM_FullDebugMode.dll.
    Т.е. почти "на лету" - после включения в выключенном состоянии потребуется перезапуск приложения, чтобы "подхватить" DLL, скопированный в результате включения, например, в рабочий каталог программы.

    ОтветитьУдалить
    Ответы
    1. Спасибо.
      Но учитывая, что "есть своё" - вряд ли когда попробую.

      Хотя - кто знает.

      Но всё равно - спасибо.

      Удалить
  2. IMHO требование проверки программистом проделанной работы в режиме FullDebugMode - очень удачный паттерн, позволяющий выявить множество проблем, и не только в своём коде.

    ОтветитьУдалить
    Ответы
    1. Но можно не "требовать", а "поставить перед фактом". Внедрив собственный менеджер. Без всяких "пасов руками" типа внешних DLL.

      Удалить
    2. Ну и собственно - зная про"мой менеджер памяти" можно "примерно представить" - как устроен FastMM.

      Что - зачастую - полезно. "Назад к основам" так сказать. http://russian.joelonsoftware.com/Articles/BacktoBasics.html

      Удалить
    3. И опять - согласен.

      Сегодня я столкнулся с тем, что "люди не контроллируют утечки памяти".

      Не на работе. На работе - я бы быстро это увидел бы.

      Удалить