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" <nfer...@gmail.com> wrote:
> Em 23 de julho de 2013 16:02, Eden Cardim <e...@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@pm.org > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer