Еще о тестировании производительности
Serg V. Gulko
s.gulko at gmail.com
Wed Jun 15 07:47:08 PDT 2011
Сережа, когда ты пишешь маленькую программу для себя или для других,
чтобы показать свою крутизну - я только 'за' функциональное
программирование:) Но как только ты начинаешь делать большое приложение,
да еще и не один, здравый смысл(ну, или зашоренность моего разума)
начинает подсказывать, что ООП - это хорошая штука. Мой пример прост,
как угол дома - последовательный проход по элементам массива с
вычислениями. Если в такой простой задаче(а в финансах, в основном, это
проходы по массивам значений) я получил разницу в 40 раз, то запускать
более тяжелый пример как то уже и не хочется:)
В Срд, 15/06/2011 в 18:34 +0400, Serge пишет:
> Это Перл. И если хочешь из него выжать максимум, нужно не писать как на Си, а использовать возможности Перл - применять функциональные алгоритмы.
> Конкретно в этом примере мало что можно наловить, ибо он как забивание гвоздей ифуной ;)
> А вот если ты найдешь чего-то посложней, там можно будет исполнить.
>
> 15.06.2011, 18:19, "Serg Gulko" <s.gulko at gmail.com>:
> > Можешь дать свой вариант Order? Пусть там будет задействовано только
> > несколько полей - open_price, side, size, pl, close_price.
> > Кстати, я не согласен насчет неприменимости ООП в высоконагруженных
> > задачах.
> > On 15 июн, 10:13, Oleg Alistratov <a... at ali.org.ua>; wrote:
> >
> >> On 15.06.2011 17:09, Serg V. Gulko wrote:
> >>>> мне кажется,что можно переписать алгоритм и ускорить работу скрипта на perl
> >>> Готов рассмотреть идеи оптимизации. Там для построения простых
> >>> getter/setter-ов используется относительно быстрый
> >>> Class::Accsssor::Fast. Заменить можно только на ручное формирование
> >>> полей, но разве это вариант? Думаю, если туда затолкать огробло Moose,
> >>> там тест и за минуту не закончился бы.
> >>> В любом случае - любые предложения по оптимизации приветствуются:)
> >> Например, блессануть не хеш, а массив. Доступ к членам по числовому
> >> индексу будет таки побыстрее, чем по текстовому. Это если все же хочется
> >> оставить объекты, чего в нагруженной вычислительной задаче лучше избежать.
> >>
> >> --
> >> Олег
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/kiev-pm/attachments/20110615/170b3fd7/attachment.html>
More information about the Kiev-pm
mailing list