27 октября 2011 г. 14:00 пользователь Ivan Petrov <span dir="ltr"><<a href="mailto:i.petro.77.00@gmail.com">i.petro.77.00@gmail.com</a>></span> написал:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
>> А можно данные каких-нибудь тестов привести в доказательство этого<br>
> тезиса? А то<br>
<br>
> будут, если проект попадет на CPAN.<br>
<br>
> Меня интересуют тесты производительности, а не юнит-тесты. Они могут (и должны)<br>
> проводиться до выкладывания в production, даже до CPAN.<br>
<br>
</div>тут сравнивать то собственно не с чем.<br>
<br>
сравнивать с DBI? этот модуль является над ним надстройкой, то есть<br>
делает предобработку данных перед трансляцией ему, соответственно<br>
будет всегда медленнее DBI работать.<br>
<br>
сранивать с DBIC? DBIC делает:<br>
1. генерацию запросов<br>
2. генерацию запросов некачественных (с точки зрения<br>
производительности SQL)<br>
3. POST-обработку выборки и сплит ее в объекты (мы отказываемся<br>
от этого сразу, ибо поскольку исключаем кривые запросы, то и<br></blockquote><div><br>Это неправда. Нормальный ORM возвращает итератор, а объекты создаёт только когда они действительно нужны.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

POST-обработка не нужна: то есть в нашем случае получается код в<br>
предельном случае, состоящий из одной инструкции bless).<br>
<br>
то есть узкое место в случае с DBIC будет база данных, которая его<br>
кривые запросы будет мучиться исполнять.<br></blockquote><div><br>Узкое место, как правило, между клавиатурой и спинкой кресла.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

соответственно единственные тесты производительности о которых можно<br>
говорить это тесты "как быстро работает темплейтный парсер".<br></blockquote><div><br>Тогда надо сравнивать ваш велосипед с SQL::Abstract, а не с DBIC.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
ну вот есть такой тестик.<br>
<br>
    SELECT<br>
        u.*<br>
    FROM<br>
        users AS u<br>
<br>
    ?if{filters.role_name} {<br>
        LEFT JOIN roles AS r ON u.rid = <a href="http://r.id" target="_blank">r.id</a><br>
    }<br>
<br>
    ?if{filters.user_name} {<br>
        LEFT JOIN user_cards AS uc ON <a href="http://u.id" target="_blank">u.id</a> = uc.uid<br>
    }<br>
<br>
    WHERE<br>
        1 = 1<br>
<br>
    ?if{filters.role_name} {<br>
        AND <a href="http://r.name" target="_blank">r.name</a> = ?{ filters.role_name }<br>
    }<br>
<br>
    ?if{filters.user_name} {<br>
        AND <a href="http://uc.name" target="_blank">uc.name</a> = ?{ filters.user_name }<br>
    }<br></blockquote><div><br>Всё, после этого запорса можно не читать. Ваша проблема не в ORM, а в том, что вы не понимаете, для чего он нужен. Внимательно прочитайте, что написал Andrii Kostenko ранее. А потом ещё раз. И ещё раз.<br>
<br>ORM -- это Object-relational mapping, а не конструктор запросов.<br></div></div><br>Удачи!<br>-- <br>Andrei Protasovitski<br>< andrei[dot]protasovitski[at]gmail[dot]com ><br>Diemen, Netherlands<br>