<div dir="ltr">Algo importante de avaliar é o quanto seu footprint vai aumentar com Perl. Eu trabalho com sistemas embarcados que já incluem o interpretador Perl e alguns módulos na própria imagem básica de distribuição e daí não tenho problema em adicionar apenas alguns módulos adicionais. Se seu sistema é baseado em x86_64 já estamos nos 1% de que o Blabos falou, ou seja, já não estamos num microcontrolador e Perl vai ser provavelmente ok, assim como Python provavelmente seria ok também. Se a imagem padrão do teu software é baseada em Debian, saiba que o próprio Debian não funcionaria sem um bom conjunto de módulos Perl instalados. Seus aplicativos, pelo que entendi, vão ser de linha de comando e vão rodar através do cron, correto? No Debian você provavelmente vai encontrar exemplos bastante próximos do que você vai fazer para modificar, extender ou se inspirar, tente usá-los como referência. </div><div class="gmail_extra"><br><div class="gmail_quote">Em 12 de dezembro de 2014 15:18, Felipe N. Oliva <span dir="ltr"><<a href="mailto:felipe@felipeoliva.eti.br" target="_blank">felipe@felipeoliva.eti.br</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<br>
<div>On 12/12/2014 14:13, Blabos de Blebe
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Opa,
<div><br>
</div>
<div>O que eu teria a dizer o breno já disse, mas reforçando,
tudo depende do que você tem disponível e do que/quanto está
disposto a pagar por isso.</div>
<div><br>
</div>
<div>Em termos de embarcados*, linguagem como Perl, Python, etc
não são indicadas, justamente por ocuparem mais memória e
terem uma performance um pouco menor em geral.</div>
<div><br>
</div>
<div>Ter menos performance aqui significa gastar mais tempo e
energia pra realizar operações equivalentes. Dependendo da
aplicação, tempo pode não ser um problema, mas o consumo extra
de bateria sim.</div>
<div><br>
</div>
<div>Normalmente, linguagens de mais alto nível pagam esses
recursos em troca do recurso "tempo do programador", ou seja,
possibilitam que o desenvolvedor crie código num nível muito
mais alto de abstração num ambiente onde ele tem tempo,
memória e energia em grande escala.</div>
<div><br>
</div>
<div>Note porém que dependendo de alguns detalhes, como o
domínio da aplicação, se usa XS ou não, etc, pode ser que a
aplicação em Perl nem fique com menos performance, se o
gargalo ficar por exemplo na taxa de transmissão do seu rádio.</div>
<div><br>
</div>
<div>A questão sempre é sobre o que você é obrigado a abrir mão
versus o que você pode ou não abrir mão.</div>
<div><br>
</div>
<div>Para 99% dos casos, Perl não vai ser indicado para
embarcados. Se você estiver trabalhando nos outros 1%, dê mais
detalhes, que vai ser extremamente interessante ajudar.</div>
<div><br>
</div>
<div>***</div>
<div><br>
</div>
<div>Antigamente tinha isso aqui:</div>
<div><br>
</div>
<div><a href="http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html" target="_blank">http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html</a><br>
</div>
<div><br>
</div>
<div>Mas creio que foi descontinuado nas versões recentes de
Perl. A referência me fugiu à memória, mas acredito ter lido
que foi descontinuado em algum release note recente.</div>
<div><br>
</div>
<div>***</div>
<div><br>
</div>
<div>Também existe isso aqui:</div>
<div><br>
</div>
<div><a href="https://metacpan.org/pod/distribution/B-C/perlcompile.pod" target="_blank">https://metacpan.org/pod/distribution/B-C/perlcompile.pod</a><br>
</div>
<div><br>
</div>
<div>***</div>
<div><br>
</div>
<div>*: O conceito de embarcados hoje é meio difuso mas
normalmente contamos situações onde os recursos são tão
limitados que não há nem sistema operacional rodando, quanto
mais uma linguagem dinâmica disponível.</div>
<div><br>
</div>
<div>[]'s</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-12-12 13:53 GMT-02:00 breno <span dir="ltr"><<a href="mailto:breno@rio.pm.org" target="_blank">breno@rio.pm.org</a>></span>:
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Oi Felipe,<br>
<br>
</div>
<div>Parabéns pela primeira
mensagem! Tomara que seja a
primeira de muitas (e não deixe de
entrar nos outros grupos também,
como Brasil-PM ou as regionais de
sua escolha - a menos que vc seja
de Cascavel, claro :D)<br>
</div>
<div><br>
</div>
Sobre a sua pergunta, depende de um
monte de fatores. Perl, assim como
todas as linguagens dinâmicas, é
feito para poupar seu tempo e
preocupação em relação a alocação de
memória, interrupções, rotinas, etc.
Naturalmente, isso vem com um preço,
em velocidade e em tamanho - tanto
em disco quanto em memória.<br>
<br>
</div>
Para mim, se você não está disposto a
pagar esse preço, a primeira pergunta
que você tem que fazer é: Perl é a
melhor linguagem para esse problema?
Ou melhor: linguagens dinâmicas são o
melhor tipo de linguagem para esse
problema? Se a resposta for "não",
escreva seu código em C, Lua ou mesmo
Assembly, e vc certamente conseguirá
chegar a um binário muito menor.
Obviamente, nesse caso o preço a pagar
é o tempo de desenvolvimento e o
cuidado necessário com alocação de
espaço, tratamento de erros,
manipulação de variáveis, etc.<br>
<br>
</div>
<div>Você diz que o programa em Perl (e
o perl em si) ocupam muito espaço para
uma app embarcada. De quanto estamos
falando? Quanto seria bom o
suficiente? De repente rola de chegar
a esse número. De repente não.<br>
</div>
<div><br>
</div>
Dito isso, se vc realmente quer diminuir
o espaço ocupado em disco, há algumas
coisas que você pode tentar:<br>
<br>
* <a href="http://perldoc.perl.org/perlembed.html" target="_blank">http://perldoc.perl.org/perlembed.html</a>
- aqui vc encontra dicas para rodar
código Perl a partir de um programa em
C. Como a compilação inclui só as libs
necessárias, de repente o resultado fica
menor para a app embarcada. Obviamente,
o resultado pode ser oposto, mas aí vc
vai ter que testar;<br>
<br>
</div>
* Você não precisa de documentação para
executar código, então pode "minificar" os
arquivos .pm e .pl na hora de embarcar o
código. O espaço em memória será o mesmo,
mas em disco, será menor;<br>
<br>
</div>
* Analogamente, se vc tem certeza do que
será utilizado e de todas as possíveis
ramificações do seu código, pode arrancar
fora subs que com certeza nunca serão
chamadas. Eu só faria isso em último caso, e
com cobertura de 100% em testes de
ramificação;<br>
<br>
</div>
<div>* Você pode também analizar a sua árvore
de dependência e ajustá-la para usar versões
alternativas e menores de determinados
módulos. Por exemplo, usar código XS em vez
de PP, módulos ::Tiny em vez da versão
completa, Moo em vez de Moose. Em alguns
casos você consegue até fazer um overhaul no
módulo e diminuir as dependências na mão
(por exemplo, criar as classes diretamente e
na mão em vez de usar um framework.<br>
</div>
<div><br>
</div>
* Existem alternativas que "zipam" o código e
descompactam em memória na hora de executar.
Acho que o PAR faz isso, mas não uso há tanto
tempo que não sei te dizer;<br>
<br>
</div>
* Algumas ferramentas como o "strip" (<a href="https://en.wikipedia.org/wiki/Strip_%28Unix%29" target="_blank">https://en.wikipedia.org/wiki/Strip_%28Unix%29</a>)
podem reduzir o tamanho do binário final
arrancando trechos não utilizados;<br>
<br>
</div>
* você pode tentar compilar o perl manualmente
usando compiladores diferentes (por exemplo, clang
ou gcc) e flags de compilação diferentes, comparar
o resultado final e escolher o que ficou menor. As
vezes os resultados são bem significativos.
Aproveite pra ler o script de configuração do
fonte do perl para desativar coisas que sabe que
não vai utilizar e que vem ativas por padrão, a
diferença no tamanho do binário e libs associadas
pode ser significativa para o seu problema.<br>
<br>
</div>
<div>Só não esqueça que cada sugestão acima vem com
um preço. Algumas vão exigir mais CPU. Outras,
mais memória. Outras, mais trabalho na hora de
fazer deploys. Outras tornam atualizações de
módulos externos bem mais difíceis. Outras exigem
muito mais lógica na hora de estruturar seu
programa. Outras... acho que vc entendeu :)<br>
</div>
<div><br>
</div>
Enfim, é isso. Boa sorte! :)<br>
<br>
</div>
[]s<br>
<br>
</div>
-b<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>2014-12-12 12:36
GMT-02:00 Felipe N. Oliva <span dir="ltr"><<a href="mailto:felipe@felipeoliva.eti.br" target="_blank">felipe@felipeoliva.eti.br</a>></span>:<br>
</span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Olá
senhores,
<div>
<div><br>
<br>
Esta é minha primeira postagem aqui na lista, e
peço a paciência de todos em caso de falar
alguma bobagem.<br>
<br>
Estou em meio a um projeto de sistema embarcado
onde meu foco é deixar o sistema o menor
possível. Meu problema é que o Perl ocupa um
espaço relativamente alto (para uma aplicação
embarcada).<br>
<br>
Alguém poderia me dar uma dica de como reduzir o
seu tamanho e do Perl em si e seus módulos?<br>
<br>
Att,<br>
Felipe N. Oliva<br>
_______________________________________________<br>
Cascavel-pm mailing list<br>
<a href="mailto:Cascavel-pm@pm.org" target="_blank">Cascavel-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
Cascavel-pm mailing list<br>
<a href="mailto:Cascavel-pm@pm.org" target="_blank">Cascavel-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Cascavel-pm mailing list
<a href="mailto:Cascavel-pm@pm.org" target="_blank">Cascavel-pm@pm.org</a>
<a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a></pre>
</blockquote></div></div>
Obrigado pelos retornos.<br>
<br>
Não sou um expert em Perl. Cheguei até o Perl pela facilidade,
documentação e os vários módulos.<br>
<br>
O papel do Perl no meu sistema é automação de processos, como:
backup, checagens e etc;<br>
<br>
A questão do espaço que tenho esbarrado são os modulos, libs, etc...
não o aplicativo em si, exemplo <a href="http://backup.pl" target="_blank">backup.pl</a><br>
<br>
Se eu estiver viajando podem falar, mas meu mundo perfeito é um
deixar o aplicativo compilado somente com suas dependências.<br>
<br>
Ainda acredito que consigo usa-lo, só me falta conseguir otimizar
essa questão do espaço.<br>
<br>
Talvez também vou utiliza-lo para Interface WEB e Sockets, mas isso
ainda é um "talvez".<br>
<br>
Att,<br>
Felipe N. Oliva<br>
</div>
<br>_______________________________________________<br>
Cascavel-pm mailing list<br>
<a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/cascavel-pm" target="_blank">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Leonardo Ruoso<br>Journalist, Perl developer and business consultant<br>Media, UFC/2006; Telecom, IFCE/1998</div>
</div>