 |
Analisando e comparando seis diferentes implementações do comando sed |
Em abriu deste ano eu escrevi o artigo minised: Um sed melhor do que o sed. sed é um comando que como seu próprio nome sugere (Stream EDitor), serve para editar/alterar as informações que são exibidas em sua tela (observação que deve ser feita é que arquivos acessados através do sed não são modificados, apenas a forma como as informações são exibidas; a não ser que as informações exibidas sejam redirecionadas ao arquivo de origem). sed Foi um dos primeiros comandos desenvolvidos para o Unix para processamento de dados e, conforme o e-mail de lançamento do kernel Linux 0.02 "intitulado Códigos livres de kernel parecido com minix para AT-386" no grupo comp.os.minix, é descrito que sed também foi um dos primeiros comandos a ser utilizado pelo Linux:
"Ainda está na versão 0.02 (+1 (muito pequeno) patch já), mas executei com sucesso bash/gcc/gnu-make/gnu-sed/compress nele."
O gnu-sed é a implementação utilizada na maioria das distribuições Linux porém, como existem diferentes implementações do mesmo comando (assim como existem diferentes implementações de todos os comandos e de todas as ferramentas), eu resolvi analisar e comparar ao menos seis delas apresentando aqui neste artigo os resultados de cada uma.
Eu analisei o gnu-sed 4.8 disponível no Fedora 35 (sed-4.8-8.fc35.x86_64); o minised 1.16 já apresentado aqui no blog; o Busybox_SED que apesar de ter originado do gnu-sed, já não possui uma unica linha de código do do gnu-sed; logo não tendo mais nenhuma relação um com o outro (para entender melhor sobre esse caso, leia o meu artigo "O Paradoxo do Navio de Teseu no mundo open source" clicando aqui); as versões do toybox 0.8.6 e 0.8.7; o 9base sed (de origem do plan9 e depois portado para outros sistemas operacionais) e por fim o sbase sed de origem do Unix e portado para outros Unixes (incluindo Linux na lista de outros Unix) que não possui versão específica. Neste artigo eu irei avaliar as implementações por:
- Licença
- Tamanho do binário
- Recursos disponíveis
- descrição de ajuda
- Desempenho
- bugs
Para os testes eu utilizei o terminal de comandos zsh por proporcionar melhores informações (inclusive uso de CPU por padrão) e devido o Bash por vezes já ter apresentado bugs que não podem nos garantir confiabilidade nos resultados (leia mais sobre os bugs que encontrei no bash clicando aqui). Em conjunto eu utilizei o comando time.
 |
Diferença de exibição de resultados do comando time entre os terminais de comando bash e zsh. |
Fiz uso dos materiais públicos aurelio, the mouseless Dev que possui até mesmo um mapa mental muito interessante, o manual gnu-sed e os próprios arquivos de testes disponibilizados pelos próprios comandos.
 |
| Mapa mental do comando sed do site The Mouseless Dev |
Ao final de cada teste, eu irei classificar uma ou mais implementações como vencedores e na conclusão do artigo eu irei classificar da primeira a terceira colocação a partir da que proporcionar a maior quantidade de vantagens. Agora vamos partir para o arrebento.
LICENÇAS
Neste primeiro tópico eu analiso quais as licenças adotadas por cada implementação levando em conta que cada licença proporciona vantagens e desvantagens. Parece um assunto irrelevante, mas trata-se de algo que pode afetar fortemente todo o mercado, todo um ecossistema e automaticamente você (se hoje o busybox estivesse sob GPLv3, provavelmente você nem teria um roteador em sua casa).
 |
| Licenças adotadas por cada implementação do comando |
Enquanto o gnu-sed está sob GPLv3+, o busybox-sed manteve-se sob GPLv2 mesmo tendo originado-se do gnu-sed (como pode ser lido no artigo O Paradoxo do Navio de Teseu no mundo open source) e é mantido pelo FFC.
 |
| Passe o cursos sobre a imagem para ler a tradução (texto original, basta clicar aqui) |
O sbase e o 9base estão sob MIT (9base sob MIT/X Consortium License); o minised foi disponibilizado sob GPL a partir da versão 1.13 e passou a ser disponibilizado sob BSD-like a partir da versão 1.14 em diante com o consentimento de Eric Raymond. O toybox está sob a clausula zero BSD (0-BSD) criada por Rob Landley que na verdade trata-se de uma Domínio Publico apenas sob o nome de BSD (com a aprovação dos próprios membros dos BSDs).
VENCEDOR: Com exceção da GPL (que possui tendência natural a declínio), todos as demais licenças são muito boas. O busybox_SED ainda pode levar alguma vantagem com a GPLv2 por não ser incompatível com o kernel Linux e ser menos negativamente impactante que a GPLv3.
TAMANHO DOS BINÁRIOS
Tenha em mente que, quanto menor o binário, melhor é em todos os sentidos (segurança, desempenho, modularidade e portabilidade). Códigos menores se tornam mais fáceis de manter e serem atualizados.
 |
| Passe o cursor sobre a imagem para ler a tradução |
Como mencionado no site do projeto embutils (que infelizmente não entrou para nossa lista), o userland dos Unix geralmente é composto de comandos dos BSDs e do projeto gnu. Na época que surgiram, as técnicas de desenvolvimento eram diferentes; os projetos focavam somente em recurso, mas não na otimização do tamanho.
 |
Passe o cursor sobre a imagem para ler a tradução |
No episódio 06 do Linux Link Radio Rob Landley menciona que na época em que era mantenedor do BusyBox curiosamente descobriu que foram escritas 833 linhas de código apenas para implementar o comando cat... E parece que não mudou muita coisa já que o gnu cat hoje ele possui 805 linhas... Outra coisa bem curiosa relatada por Rob é que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k.... Desenvolvedores de embarcados são declaradamente inimigos mortais da glibc.
Para dispositivos como embarcados e até mesmo para o processo de boot, binários grandes são simplesmente inviáveis e parece não fazer sentido, mas mesmo em ambientes como desktop, servidores e até supercomputadores binários menores também são extremamente importantes pois assim o sistema consegue melhor desempenho em seus processos, é carregado mais rápido pela cache L2, deixa o buffer mais livre.
Há ressalvas a serem consideradas durante as avaliações como sua ligação se dinâmica ou estática, quais bibliotecas foram utilizadas, qual compilador e com quais flags e assim por diante. As ressalvas foram feitas em asteriscos (*).
 |
| Tamanho de cada implementação do comandos sed. |
*Relembrando aqui que menor significa melhor
**Eu compilei o minised estaticamente a dietlibc.
***Consta no site do busybox que o busybox_SED possui 89K; porém, após baixar, seu tamanho final é de 92K (também likado estaticamente. Baixe aqui para conferir).
**** Eu compilei o sed do toybox dinamicamente para que pudéssemos saber o seu real tamanho.
VENCEDOR: Neste caso eu deixo três colocados. O toybox sed em primeiro com apenas 36k; o minised em segundo com apenas 44k, e o sbase sed em terceiro com 56K.
.png "Comparação de tamanhos entre minised linkado estaticamente e toybox sed linkado dinamicamente") |
| Comparação de tamanhos entre minised linkado estaticamente e toybox sed linkado dinamicamente |
 |
| Comparação de tamanhos entre minised linkado tanto dinamicamente quanto estaticamente |
Além do mais, eu testei as versões binárias do toybox já disponibilizadas pelo próprio projeto que são linkadas estaticamente, e os comandos estão incorporados ao terminal (sendo um deles o sed). Mesmo contendo 231 comandos incorporados a si, o toybox 0.8.7 possui apenas 716K.
.jpg "Reparem a quantidade de comandos dentro do toybox 0.8.7 em apenas 716k (sendo um deles, o comando sed que está selecionado nesta leu).") |
| Reparem a quantidade de comandos dentro do toybox 0.8.7 em apenas 716k (sendo um deles, o comando sed que está selecionado nesta imagem). |
RECURSOS
É agora que constataremos se o tamanho dos binários fazem jus à quantidade de recursos. Reforçando o que foi dito no tópico anterior, quanto menor o binário, melhor é porém, não vai adiantar muito o binário ser pequeno e enxuto se não conter os recursos necessários para a sua adoção.
Além do mais, esse é um ponto extremamente importante pois uma regra histórica que não falha é que, mesmo que um programa contenha certos bugs, mas possui os recursos que as pessoas querem (ou precisam), elas aceitam conviver com tais bugs. Tudo uma questão de prós e contras; além do que os bugs podem ser corrigidos ao longo do tempo (ou não, vai saber a complexidade).
Podemos dizer que neste tópico o gnu-sed dispensa explicações pois um ponto forte das ferramentas do gnu (não por total mérito seu) mas que é mal divulgado pelo próprio projeto é exatamente a parte de recursos possuindo até mesmo extensões próprias. OK para o gnu-sed.
No arquivo BUG do minised é descrito "Focarão nas conformidades POSIX e pequeno tamanho - extensões do GNU sed provavelmente não serão aceitas". O minised possui um diretório chamado tests que após compilá-lo, podemos executar o script run, conforme descrito em seu arquivo Makefile (cd tests; ./run ../minised) ou bastando executar o comando make check que se encarregará de fazer esse trabalho (realizando o total de 68 testes). Um dos testes falha (especificamente o empty-lhs), mas como descrito no próprio resultado, essa falha é intencional.
 |
| Testes disponibilizados pelo próprio minised |
O toybox também disponibiliza seus próprios arquivos de teste também dentro do diretório tests. No total, ele realiza 91 testes com o toybox sed.
 |
| Teste disponibilizados pelo próprio toybox |
O toybox sed possui uma lista dentro do seu próprio código fonte com algumas pequenas pendências a serem ajustados como "fazer y// lidar com delimitadores unicode, lidar com retorno de erro a partir do emit(), error_msg/exit consistentemente", "Qual a coisa certa a se fazer com -i quando escrever as falhas? Skip ou next?". Eu considero uma lista baixa; lógico que prefiro ver estas questões sanadas, mas são consideráveis.
O Busybox sed também possui uma pequena lista comentada em seu código fonte de apenas três de pequenos detalhes a serem acertados.
Eu não encontrei algumas pendências tanto no sbase quanto no 9base e não foram ruim nos testes.
VENCEDOR: Empate geral. Em todos os testes que eu realizei, todas as implementações conseguiram processar com sucesso.
DESCRIÇÃO DE AJUDA
Descrições de ajuda (--help e manpages) assim como as licenças, parecem ser irrelevantes, porém pense no seguinte cenário; você está administrando o seu sistema, precisa consultar uma opção e sabe que tal comando não possui opção de ajuda. Até aí, tudo bem, basta consultar a manpage... Certo?...
A resposta é... depende de qual distribuição estamos falando. Distribuições como Alpine Linux ou Porteus não possuem manpages por padrão. E se de repente você não possui acesso a internet? O que você faz?...
Do que adiante um programa conter todos os recursos necessários sendo que não vem com as informações de como utilizá-los? Seria o mesmo que uma TV não acompanhar manual de instruções. Alias, eu já vi empresas adotarem uma certa distribuição devido a facilidade em encontrar informações e soluções de problemas. Então, por mais que pareça algo irrelevante, descrições de ajuda é algo extremamente importante.
E aqui vamos nós para a nossa analise. O minised, apesar de possuir uma boa manpage, não possui a opção --help por padrão. Eu acredito que poderia possuir ao menos uma leve descrição assim no sbase e no 9base. Ou melhor, assim como o busybox_SED; enxuta e explicativa.
 |
| Descrição de ajuda do minised e do sbase sed |
 |
| descrição de ajuda do busybox sed |
O gnu-sed e o toybox sed são os que melhores implementam tais descrições. Aqui eu postei apenas uma porção de toda a descrição de ambos.
 |
| Descrição de ajuda do gnu-sed |
 | ||
| Descrição de ajuda do toybox sed [27/11/2023] Estranhamente na versão 0.8.10 do toybox, a opção --help ficou bem limitada assim como da implementação do sbase e do Solaris. Porém, como já mostrado tanto aqui no blog quanto no canal, o toybox possui a opção help seguido do comando. Então, digitando toybox help sed, o comando sed do toybox oferece opções muito mais completa.
|
VENCEDOR: Empate entre o toybox sed e o gnu-sed
POSSÍVEIS BUGS
Já que falamos de recursos, agora vamos tratar de... bugs. O que é uma parte um pouco complicada de se tratar já que difícil constatar a real quantidade de bugs de um programa. Como todos sabem, há relatos de bugs que só foram encontrados mais uma década após sua existência. O bug estava lá mas só foi detectado dois de tanto tempo.
Então, o que podemos fazer aqui é relatar os que já estão reportados em bug reports, procurar por informações em man pages, comentários dentro dos códigos, informações nos arquivos README e BUGS ou... da forma mais árdua, testando mesmo assim como já mostrei alguns que reportei e podem ser conferidos no meu canal clicando aqui. O que alias não é o meu interesse.
Por exemplo, no arquivo BUGS do minised é descrito como não havendo a necessidade de regressão até o momento; porém, como puderam acompanhar no inicio, vale ressaltar que sua base de código é bem pequena (o que é muito vantajoso). Apesar disso, eu encontrei apenas dois comentários de FIXME nos códigos sedcomp.c e sedexec.c (/* FIXME: scan for the brace end */ e /* FIXME: lastep becomes start */).
O mesmo ocorre no toybox sed (tendo sua base de código ainda menor que do minised). A primeira versão do sed no toybox surgiu na versão 0.5.1 (em Novembro de 2014). De lá para cá, poucos bugs foram encontrados (total de 11 bugs encontrados e corrigidos desde então. Um deles pode ser conferido clicando aqui) e poucos deles eram críticos. O minised teve 12 correções desde a versão 1.3 que podem ser lidos em seu README.
E que comece o choro e ranger de dentes. O gnu-sed é o que mais podemos encontrar bugs. Em seu próprio git (clicando aqui) ou podem ser conferidos no Debian Bugs clicando aqui apresentam uma lista de bugs conhecidos.
Já o Busybox_SED possui apenas duas informações de FIXME em seu código mas é possível consultar bugs em seu próprio bug reports clicando aqui.
No código do sbase sed existem 20 comentários com o dizer FIXME. Estes comentários descrevem correcções que ainda são necessárias. Foi difícil encontrar algo relacionado ao 9base sed, há sim correções ocorrendo e podem ser conferidas no próprio git do plan9port (clicando aqui), mas não é uma lista fácil de encontrar (muito menos especificamente de seu sed).
VENCEDOR: Com excessão do gnu-sed, todos os demais apresentaram baixa quantidade de bugs.
DESEMPENHO
E por fim, a parte que a galera vai para delírio: benchmarks... Parece que a galera pira com essa palavra. Aqui eu considerei analisar tanto o uso de CPU quanto o tempo para a concluir as operações. E obtivemos os seguintes resultados:
Estranhamente tanto o gnu-sed, o sbase sed, o 9base sed e o busybox_SED se comportam da mesma forma. eles sempre se mantêm na margem de 86-89% de uso de CPU, nunca a menos nem a mais do que isso. Mas não devemos analisar unicamente o uso de CPU pois, de certo forma, isso pode significar tanto algo bom quanto algo ruim; tudo vai depender muito da situação.
Reparem um exemplo disso na imagem abaixo onde fiz uma analise entre o minised e o gnu-sed sendo eles separados pela faixa azul. Enquanto o gnu-sed manteve o uso de 89% de CPU, o minised desta vez fez uso de 106%. Apesar do uso de CPU do minised ter sido mais alto, o mimised concluiu sua operação em 120ms enquanto que o gnu-sed concluiu a mesma operação em 284ms.
 |
| Comparação de uso de CPU e tempo de conclusão entre minised e gnu-sed |
Para que o gnu-sed, sbase sed, 9base sed e o busybox_SED consigam concluir as operações no mesmo tempo que o minised, seria necessário que utilizassem entre 136,17% a 161,87% a mais de CPU além dos 89% já utilizado. O que totalizaria entre 225,17% a 250,87% de uso de CPU.
VENCEDOR: Empate entre o minised (utilizando entre 61% - 76% de CPU porém, com menor tempo de execução) e toybox sed (utilizando entre 50% - 76% de CPU, algumas vezes atingindo 88%). Os demais ficam entre 86% a 89% de uso de CPU e o mesmo tempo de execução.
CONCLUSÃO
O primeiro lugar fica para o toybox sed com 6 pontos. O minised em segundo com 5 pontos perdendo apenas na descrição de ajuda apesar que possui uma boa manpage. Então poderíamos declarar empate entre os dois já que o minised possui desempenho melhor do que o toybox sed.
O segundo lugar ficaria empatado entre o busybox_SED com quatro ponto (tamanho, recursos, descrição de ajuda e poucos bugs) e o sbase sed (licença, tamanho, recursos e poucos bugs). O 9base sed teve três pontos (licença, recursos e bugs) e o gnu-sed apenas dois pontos (recursos e descrição de ajuda).
 |
| Conclusão da analise das implementações do sed |
 |
| sd é um comando que pode substituir find, sed e awk. |
Nenhum comentário:
Postar um comentário
Viu algum erro e quer compartilhar seu conhecimento? então comente aí.
Observação: somente um membro deste blog pode postar um comentário.