четверг, 24 октября 2013 г.

Массовое использование интерфейсов "вообще" и InterlockedIncrement/InterlockedDecrement в частности...

Массовое использование интерфейсов "вообще" и InterlockedIncrement/InterlockedDecrement в частности ведёт к значительному снижению производительности.

Если хотите - у меня есть несколько unsuccess story.

Подтверждённые замерами AQTime.

Это кстати на месте "авторов ARC" - я бы принял бы во внимание.

P.S. Когда-то (в отсутствии примесей) мы поддались "массовой истерии интерфейсов" и спутали "интерфейсную совместимость" с совместимостью "поведенческой". Ну это как рассматривать "шаблоны C++" и "абстрактные классы C++" и "множественное наследование". Тут - тонкая грань. И ДАЛЕКО не всегда нужна ИМЕННО "интерфейсная совместимость", гораздо чаще нужна совместимость "поведенческая".

P.P.S. Меня ТОЛЬКО ОДНО удивляет - КАК в Objective-C при вызове ВСЕХ методов по имени (селектору) удаётся поддерживать приемлемую прозводительность. ДАЖЕ на МОБИЛЬНЫХ устройствах. ДАЖЕ типа 3g.

Дело в том, что retain/release/autorelease - ТАМ совсем далеки от InterlockedIncrement/Interlockeddecrement. Но вроде - работает.

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

  1. Очень в своё время хотелось в Delphi интерфейсов БЕЗ ARC. Просто как абстрактные протоколы.

    ОтветитьУдалить
    Ответы
    1. Так НЕ ВОПРОС...
      Сделайте AddRef == -1 и Release == -1.
      Делов-то. Сам не раз так делал...

      Удалить
    2. Я НА САМОМ деле - ПОНЯЛ в чём вопрос... Хочется "иногда" отдавать интерфейсы, а "иногда" - ПРОТОКОЛЫ. Тут AddRef - КОНЕЧНО не поможет...

      Удалить
    3. "Очень в своё время хотелось в Delphi интерфейсов БЕЗ ARC. Просто как абстрактные протоколы."

      О как вы правы..

      Удалить
  2. >>Если хотите - у меня есть несколько unsuccess story.

    Ага, по сути получается, что мы опять влезаем в голую инженерию управления памятью. Голую, т.к. легко красивые одежды срываются при первом же дуновении ветерка рациональности.

    Мы говорим о потери производительности на чём? У меня в голове есть виртуальные примеры, ограниченные достаточно узкими рамками задач о "интеллектуализации" текста. Но такая "интеллектуализация" в контексте прикладных задач сводится к "пре-процессингу" больших объемов статического текста, что:
    а) не требует решения в прикладном клиентском ПО
    б) выполняется однократно для множественного обращения к информационному ядру системы (пре-процессинг)
    в) не вовлечено в критический по времени system response
    ... следствие: такого рода задача решается на специально подготовленном аппаратном обеспеении + с привлечением специализированных алгоритмов + отдельным способом отобранным и высококвалифицированным специалистом.

    Вопрос: зачем перегружать "вижуал бейсик"?

    ОтветитьУдалить
    Ответы
    1. "Ага, по сути получается, что мы опять влезаем в голую инженерию управления памятью."
      я её занимаюсь почти 19-ть лет :-)

      Удалить
    2. "Мы говорим о потери производительности на чём? У меня в голове есть виртуальные примеры, ограниченные достаточно узкими рамками задач о "интеллектуализации" текста. Но такая "интеллектуализация" в контексте прикладных задач сводится к "пре-процессингу" больших объемов статического текста"
      -- вот ошибаетесь :-)

      Удалить
    3. Вот я сейчас программирую "мобильные устройства" и "вспомнил эру БК-0010.01" :-)

      Удалить
  3. а как в objc retain/release устроен? я думалл какраз на интерлокитах...

    ОтветитьУдалить
    Ответы
    1. На интерлокедах... Но он ещё и "динамичность вызова" добавляет.. и "ничего не тормозит".. что - СТРАННО.. но факт остаётся фактом...

      Удалить
    2. ну это да,есть у меня подозрение что вся эта "динамичность" компилятором потом как-то хитро в "статичность" превращается... не знаю только как ))

      Удалить
    3. ну судя по отладчику - это не так... зовётся obj_c_send_msg
      да и перекрывать эти методы - запросто можно... и это - работает..

      не знаю.. "магия"... дальше в отладчике - я не ковырялся...

      Удалить
    4. Есть у меня кстати ОДНА мысль на этот счёт.. Если строки Imutable... а они таки Immutable - ничто не мешает сделать "мапу" и VMT по индексам.. Но это пока лишь - "догадка"...

      Удалить
    5. Если я бы это делал, то я в КОМПИЛЯТОРЕ просто построил бы статическую СКВОЗНУЮ "мапу" (строка, индекс), и сделал бы "классические" VMT но с дырками. И звал бы методы не по "имени", а по индексу. Благо есть понятие "селекторов". Ну я бы лично - так бы и сделал...

      "Мапу" - от ВСЕХ возможных имён. В EVD с тегами кстати так и сделано...

      Удалить
    6. А уж для "системных вызовов" - так точно.. Зарезервировал бы под них "специальные индексы"...

      Удалить
    7. А в "дырках" бы я как раз вставил или вызов "интерцепторов" или trow "No Method".

      Удалить