elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
Бизнес-логика
elizarov

Зачем оптимизировать хеш-таблицы для кэширования объектов в бизнес приложениях? Разве там на них уходит процессорное время? Это один из вопросов, который мне задали после моего выступления с докладом про быстрые структуры данных. А на что уходит время в бизнес приложениях? Ведь во многих из них нет сложных задач, где применив эффективный алгоритм с меньшей асимптотической сложностью можно было бы легко добиться ускорения в разы. Бизнес-логика редко превосходит по сложности цикл, в котором происходит суммирование чисел. Цикл, который я использовал для сравнения производительности различных хеш-таблиц является вполне репрезентативным примером бизнес-логики типичного приложения.

Чтобы узнать на что же именно уходит время в этом цикле, надо отделить кэш объектов от собственно бизнес-операции суммирования. В рамках своей инфраструктуры для сравнения производительности хеш-таблиц, я написал специальную реализацию OrderList, которая на самом деле не является ни каким кэшом объектов, а заранее знает в каком порядке будет производиться доступ к объектам Order и складывает их в простой массив Order[] a. Я реализовал метод getById , которые игнорирует переданный ему id:

    public Order getById(long id) { 
        if (pos >= a.length) 
            pos = 0; 
        return a[pos++]; 
    } 

Всё это сделано только для того, чтобы можно было измерить скорость работы тем же самым кодом, который использовался для оценки производительности хеш-таблиц:

    private int accessOnce() { 
        int checkSum = 0; 
        for (long id : seq.access) 
            checkSum += impl.getById(id).getCheck(); 
        return checkSum; 
    } 

Результат — 16 нс на итерацию цикла. В то время как при использовании кэша объектов, при самом лучшем стечении обстоятельств, время было 68 нс на операцию. А при реализации в лоб, через стандартные библиотечные классы, более 200 нс. Видно, что именно поиск элемента в хеш-таблице, а не бизнес-логика этого кода, занимает бо́льшую часть времени.

По мои наблюдениям, во многих бизнес-приложениях бо́льшая часть времени уходит не саму бизнес-логику, а не неоптимальные реализации коллекций объектов, которыми постоянно манипулирует приложение. Узкое место редко бывает в каком-нибудь одном месте. Но именно системное использование оптимальных, подходящих в данном конкретном месте классов-контейнеров, устранение лишнего копирования данных, и вообще забота о компактности используемых приложением структур данных (для уменьшения занимаемой памяти) позволяет в разы повысить итоговую производительность.


  • 1
>>>Разве там на них уходит процессорное время?
может у спрашивающего в софте вообще не юзаются хэш-таблицы )))

Хеш-таблицы это лишь пример, который я использовал для своего доклада. Списки, массивы и т.п. — такой подход применим много где.

да это то понятно
p.s.
недавно в одном форуме по старым компам обсуждали о том на каком языке учить ребенка программить, я говорил что бейсик на msx-2 или spectrum вполне себе подходит, оппонент сказал что нет мол, надо на JavaScript программить учить, на мой вопрос "почему?" ответил что там есть хэш-тфблицы, на мое упоминание о том, что вообще то никто не мешает на бейсике написать хэш-таблицу и юзать, он возмутился и сказал что "да вы что? как работают хэш таблицы знают долт процента!".. такое вот сакральное знание

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

Так тоже бывает. Об этом тоже буду писать и говорить. Но, кстати, такие проблемы обычно легко диагностируются именно тем, что цпу не грузит.

диагностируется может и проще (хотя тоже есть варианты - цпу может улетать в контекст свитч, спинлоки (в общем java performance tuning в помощь)) а лечится на порядки сложнее :((, т.к. проблема размазана по коду/архитектуре и чем больше система - тем хуже (в общем классический интерпрайз).
по сравнению с:
1. запрофайлил под 100% usertime
2. заменил одну структуру на другую

это я к тому что хоть бизнес логика как правило O(1) пишут ее через высокохудожественный зад который кнуту с корманом и не снился

Edited at 2012-06-28 02:54 pm (UTC)

Тоже справедливо. Это даже хорошо когда есть кокретное узкое место. А вот когда очень далекий от оптимального код тонким слоем размазан всюду...

  • 1
?

Log in

No account? Create an account