[SP-pm] Filosofias de Desenvolvimento [Was: flamewar mojo vs catalyst]

[Eden Cardim]

Essa avaliação está tão errada (tanto filosoficamente, quanto tecnicamente)
que a resposta não cabe num email. Quem sabe um dia eu arrumo o tempo e a
paciência pra escrever um blog. Hoje, esse tempo é mais bem-investido em
contribuições de código.
On Jul 23, 2013 1:52 PM, "Nelson Ferraz" <nferraz em gmail.com> wrote:

> Em 23 de julho de 2013 16:02, Eden Cardim <eden em insoli.de> escreveu:
> > Nem é tão gordo assim, na real, se você rodar o Perl::Metrics::Simple
> > no repositório de ambos, vai ver que de fato, o Mojo é mais gordo:
> >
> > http://pastie.org/8167416
> > http://pastie.org/8167419
> >
> > O mojo além de ter quase o dobro de código, o código existente é mais
> > complexo. Mas isso é porque ele oferece mais funcionalidades
> > out-of-the-box.
>
> Existem várias maneiras de se medir a gordura de um software. :)
>
> Se você considerar as dependências do Catalyst, ele é muito mais
> pesado do que o do Mojolicious:
>
> $ valgrind --trace-children=yes ./hello.pl cgi
> ==69320== HEAP SUMMARY:
> ==69320==     in use at exit: 15,848,999 bytes in 218,306 blocks
> ==69320==   total heap usage: 443,519 allocs, 225,213 frees,
> 31,393,607 bytes allocated
>
> $ valgrind --trace-children=yes script/hello_cgi.pl
> ==69129== HEAP SUMMARY:
> ==69129==     in use at exit: 30,403,225 bytes in 367,771 blocks
> ==69129==   total heap usage: 953,305 allocs, 585,534 frees,
> 68,755,287 bytes allocated
>
> A razão de usarmos cgi no exemplo acima é porque só queremos saber a
> memória consumida pela aplicação e seus módulos.
>
> Mas usando o daemon a diferença é ainda mais acentuada:
>
> $ valgrind --trace-children=yes ./hello.pl daemon
> ==69136== HEAP SUMMARY:
> ==69136==     in use at exit: 15,346,874 bytes in 213,371 blocks
> ==69136==   total heap usage: 429,907 allocs, 216,536 frees,
> 29,530,889 bytes allocated
>
> $ valgrind --trace-children=yes Hello/script/hello_server.pl
> ==69163== HEAP SUMMARY:
> ==69163==     in use at exit: 31,619,768 bytes in 381,456 blocks
> ==69163==   total heap usage: 995,648 allocs, 614,192 frees,
> 74,499,357 bytes allocated
>
> Ou seja: o Catalyst é (em termos de memória) 2.5 vezes maior do que o
> Mojolicious.
>
> ***
>
> Usando o Devel::NYTProf podemos ter uma idéia do número de instruções
> que são executadas quando o Mojolicious e o Catalyst são executados:
>
> $ perl -MDevel::NYTProf ./hello.pl cgi # Mojolicious
> $ perl -MDevel::NYTProf script/hello_cgi.pl # Catalyst
>
> Resultado:
>
> Mojolicious: 34.195 statements
> Catalyst: 731.191 statements
>
> Ou seja: o Catalyst executa 20 vezes mais instruções do que o
> Mojolicious durante a inicialização.
>
> A comparação acima pode não parecer muito justa, pois nós sabemos que
> o Catalyst tem que carregar muito mais módulos do que o Mojolicious no
> início; mas isso dá uma boa indicação da complexidade algoritmica dos
> dois frameworks.
>
> Vamos comparar também o número de instruções executadas no start() do
> Mojolicious com o setup() do Catalyst:
>
> Mojolicious: 221 statements
> Catalyst: 23.898 statements
>
> Uma diferença de 100x em favor do Mojolicious.
>
> ***
>
> Será que isso reflete de alguma forma nos tempos de resposta e
> escalabilidade?
>
> Acho que não, pois, na maioria das vezes, o gargalo está na base de
> dados, e não na aplicação.
>
> Mas isso quer dizer que o Mojolicious é "melhor"?
>
> Também não.
>
> Como muitos já disseram, o Catalyst, com sua arquitetura altamente
> modular, é mais flexível do que o Mojolicious.
>
> Mas essa flexibilidade vem com um preço -- o que eu procurei mostrar é
> que, por diversas métricas, o Mojolicious é mais leve (e
> algoritimicamente simples) do que o Catalyst, mesmo considerando que
> vem com mais funcionalidades "out-of-the-box".
>
> Resta saber o que você valoriza: flexibilidade ou simplicidade?
>
> Eu fico com o antigo slogan da Apple: "Simplicity is the ultimate
> sophistication". :)
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130723/8086be54/attachment-0001.html>