Sistemas Unix-like não "chamam funções executando novos processos". Eles (agora) compartilham bibliotecas como praticamente todos os outros sistemas operacionais relativamente modernos.
Shells, por outro lado, executam outros processos para executar determinadas tarefas. Mas nem todos. Eles têm funções embutidas, implementadas diretamente no shell (ou através de bibliotecas compartilhadas) para as tarefas mais comuns e simples ( echo , por exemplo, é implementado como um built-in por um monte de shells).
(O shell% windows cmd não é diferente dos shells Unix nesse aspecto, BTW.)
Criar um processo em sistemas modernos do tipo Unix é certamente mais caro do que fazer uma chamada de função durante o processo, mas não por uma margem tão grande. Os kernels são otimizados para bifurcações rápidas, usando técnicas como copy on write para gerenciamento de espaço de endereçamento para acelerar a "clonagem" "de processos e compartilhando as páginas de texto (código) de bibliotecas dinâmicas.
Se todos os executáveis da sua máquina que pudessem ser chamados de um script de shell fossem implementados como uma biblioteca compartilhada:
- iniciar seu shell levaria um lote de tempo (e memória) apenas para carregar tudo isso na frente (mesmo com o cache, o vinculador dinâmico tem um trabalho não trivial a fazer, e as bibliotecas seções de dados, não apenas seções de texto - estamos falando de centenas, senão milhares de bibliotecas aqui)
- você teria que carregar cada biblioteca necessária sob demanda - possivelmente um pouco mais rápido do que iniciar um processo, mas a vantagem aqui é muito pequena. E a parte de dados de suas bibliotecas compartilhadas se torna realmente difícil de gerenciar (o estado global de seu shell agora depende do estado de muitos códigos e dados não relacionados carregados em seu espaço de endereço).
Então, você provavelmente não ganharia muito para o uso típico, e a estabilidade / complexidade se torna mais um problema.
Outra coisa é que o modelo de processo separado isola cada tarefa com muita eficiência (assumindo gerenciamento e proteção de memória virtual). No modelo "tudo é uma biblioteca", um bug em qualquer biblioteca de utilitários pode poluir (ou seja, corromper) todo o shell. Um bug em algum utilitário aleatório pode matar completamente o processo do shell.
Este não é o caso para o modelo multi-processo, o shell é protegido contra esse tipo de bug nos programas que executa.
Algo mais: menor acoplamento. Quando olho para o que está no meu diretório /usr/bin agora, tenho:
- executáveis ELF de 64 bits,
- executáveis ELF de 32 bits,
- Scripts Perl,
- Scripts shell (alguns deles executam programas Java),
- scripts Ruby e
- scripts em Python
... e eu provavelmente não tenho o sistema mais chique por aí. Você simplesmente não pode misturar os dois primeiros tipos no mesmo processo. Ter um intérprete em andamento para todos os outros simplesmente não é prático.
Mesmo que você olhe apenas para o formato de arquivo "binário nativo", ter a interface entre os "utilitários" sendo fluxos simples e códigos de saída torna as coisas mais simples.
Os únicos requisitos nos utilitários são implementar as chamadas ABI e de sistema do sistema operacional. Você não tem (quase) nenhuma dependência entre os diferentes utilitários. Isso é extremamente difícil, ou simplesmente impossível, para uma interface em processo, a menos que você imponha coisas como "tudo deve ser compilado com a versão X do compilador Y, com tais e tais flags / configurações.
Existem coisas para as quais as chamadas em processo fazem muito sentido no desempenho, e elas já são, muitas vezes, feitas como internas pelas camadas. Para o resto, o modelo de processos separado funciona de forma muito eficaz, e sua flexibilidade é uma grande vantagem.