Dotnet Core 3 - Hello World (Apenas 40 megabytes de memória)

[Rodrigo_P_A]

Ou seja, 400Mb é loucura ?

Eu não sou dono da razão, mas pelo pouco conhecimento que eu tenho, seria caso de internação com medicação pesada

[chipselect]

Não acho que o .NET foi feito pensando em performance extrema para ser comparado com c/c++, acredito que ele é mais voltado para o mercado que o Java atua e, nesse quesito, não tem muita diferença de consumo de memória entre o código em CLR e bytecode java rodando numa JVM.

Esse consumo excessivo sendo comentado, em boa parte, seria por causa da máquina virtual que deve ser carregado junto. (CLR é tratado como VM no livro "Professional .Net Framework 2.0")

Um simples HELLO WORD pode consumir uma memória absurda, mas um HELLO WORD com duas mensagens não vai dobrar a memória usada, vai aumentar muito pouco na verdade.

O .NET Core que veio substituir o .NET Framework é, teoricamente, mais rápido que seu antecessor mas não vai eliminar o overhead da máquina virtual necessária, só que garante a execução em múltiplas plataformas de um jeito menos dolorido que os aplicativos em Java (pelo menos na minha opinião).

Em contrapartida, a programação em C# ou F# com o Visual Studio te dá um bom controle do projeto, ajudando bastante a manter projetos de médio porte, pois seria um problema para nós aqui na empresa, manter e evoluir um sistema que já passa de 500 mil linhas de código C# sem a ajuda das facilidades que essa plataforma nos dá, ainda mais mantendo a execução em multiplataforma.

Mesmo em um sistema desses, consigo rodar tranquilamente 12 sistemas em paralelo em um servidorzinho dual core com apenas 4G de RAM, onde neste mesmo servidor, apenas um erp ODOO 11 (Python) rodando comeu mais da metade da sua memória. É uma comparação sem muito sentido, pois o ODOO e o meu sistema possuem finalidades diferentes e, da mesma forma, comparar C/C++ com .NET Core não é algo tão simples que possa ser feito apenas com uma ou duas métricas, pois isso penderia apenas para um dos lados, se perdendo a visão geral.

Agora, se o objetivo for fazer aplicações para Desktop ou mobile, talvez essa tecnologia não seja a mais indicada para você, pois o NET CORE ainda carece um pouco de amadurecimento nesse quesito, e o XAMARIN (que usa o NET Framework e ainda não vi ele com NET CORE) sofre com a concorrência como React Native, IONIC e etc, mas essas outras tecnologias também comem memória, veja o consumo médio de memória do React Native e IONIC nesse link: https://www.simform.com/react-native-vs-ionic

[Rodrigo_P_A]

Para mim faz sentido, meu hardware possui apenas 64MB de RAM.

[chipselect]

Para mim faz sentido, meu hardware possui apenas 64MB de RAM.

Dificilmente alguém usa um servidor hoje em dia com 64MB de RAM, só se for IOT ou algo do tipo. Se você for orçar um servidor hoje para TI, vai ser um Xeon da vida a partir de 8GB de RAM, ou o seu pessoal de TI está mais de 10 anos atrasado. Mesmo um PC hoje em dia vai vir com 1 ou 2G de RAM... e pra desktop hoje isso é meio pouco também.

Repetindo novamente: O principal foco do .NET Core é para aplicações multiplataforma grandes, onde precisa de uma facilidade de organização e código facilmente escalável em tamanho.

Rodrigo, você poderia elucidar melhor o motivo de ver sentido nessa comparação?

Se for só porque seu hardware tem pouca memória, você deveria dar uma analisada melhor nessa tecnologia... pelo menos já chegou a verificar os requerimentos do .NET Core? A versão atual (3.0 e daqui a pouco a versão 3.1) só tem para 64 bits, e exige várias bibliotecas no linux, dificilmente um hardware de 64MB de ram vai conseguir cumprir com esses requisitos sem comprometer usabilidade/performance. Resumidamente, não tem sentido algum em usar .NE Core 3 só com 64MB de RAM.

Segue link:
https://docs.microsoft.com/pt-br/dotnet ... =netcore30

[Red Neck Guy]

A maior vantagem do dotnet são todas as classes do framework. Ali tem muita coisa abstraída e muita coisa útil.
Esse consumo de memória é sim culpa do runtime e das bibliotecas mínimas pra fazer o bootrap da coisa.
Tipo uma aplicação C que escreve na tela no Linux é basicamente chamadas de sistema, por isso ela fica pequena.
Talvez o benchmark deveria ser algo mais elaborado pensando em algo que deixe o dotnet mais em evidência, como acesso a uma base de dados relacional, cruzamento com uma coleção e consula com LINQ.

[Rodrigo_P_A]

Em uma outra comparação que eu citei aqui faço acesso a banco de dados, webservices, além de um monte de outras coisas, consumindo apenas 12MB.

[chipselect]

Em uma outra comparação que eu citei aqui faço acesso a banco de dados, webservices, além de um monte de outras coisas, consumindo apenas 12MB.

Acho que o correto, para título de comparação, é colocar tudo na mesma escala e padrão, mas como fazer isso para comparar ferramentas totalmente diferentes? É igual comparar uma talhadeira com uma chave de fenda só porque as pontas delas são parecidas.

Fazer um benchmark entre C#, PHP e JAVA da vida talvez faz sentido, mas como separar o C# de um dos frameworks da Microsoft (NET CORE, NET Framework, NET Standar ou NET MicroFramework pois C# da MS não gera código fora deles)? Mesmo uma comparação entre PHP e NET CORE não é tão simples, pois PHP é uma linguagem e o NET CORE é um Framework! Compare Laravel com NET CORE e veja se a Microsoft fez um serviço razoável ou não:
https://medium.com/@jamesjudd_21057/ben ... c1c3e9663d

Para que um benchmark entre NET CORE (framework) e C/C++ ou Pascal e etc tenha algum sentido, teria que encontrar uma situação comum e de mesma usabilidade para ambos. C/C++ não é para WEB hoje em dia e muita coisa em C# tem foco em WEB e aplicações grandes, mas em termos de performance e footprint de memória, dificilmente o NET CORE vai bater o C/C++, só se o programador C/C++ for muito ruim.

Comparar o NET CORE (Framework) com C/C++ (linguagem) é, de grosso modo, como comparar uma carreta (NET CORE) contra um carro de corrida (C/C++, pascal...) e querer que a carreta tenha peso (Memória) ou velocidade similar ao do carro de corrida. Isso é algo que não tem uso prático. Se for olhar pelo trabalho realizado pelo motorista por tempo (= horas de programação) em relação a quantidade de programação (= carga transportada), a carreta faz muito mais em uma única viagem, o carro de corrida sequer foi feito para levar carga, daí ele perde feio pra carreta, pois nesse caso, o carro de corrida só vai ganhar da carreta se ele conseguir levar tudo em uma única viagem sem quebrar (pouca carga = aplicação pequena).

Agora, se o alvo é um sistema pequeno ou minúsculo, não faz sentido usar JEE (JAVA) ou NET CORE (VB.NET, C#, F#)... pois por ser muito pequeno, não vai aproveitar das capacidades e facilidades de uma linguagem voltada para desenvolvimento de sistemas grandes, usando e abusando de padrões de projetos, principalmente como inversão de controle ou injeção de dependência, frameworks para cada camada ou função e etc.

Gostaria de entender como vocês querem comparar um Framework (NET CORE) com uma linguagem de programação sem ser injusto para um dos lados, pois são ferramentas totalmente diferentes. Talvez seja até mais fácil comparar a CPU de uso genérica (como o Intel Core I9) contra um DSP como o Blackfin da Analog Devices (outra comparação um tanto quanto fora da casinha, mas muito menos do que NET CORE vs C/C++ ou afins). Se estiver cogitando o uso do NET CORE em plataformas enxutas, como ter só 64MB de RAM, já começou errado na escolha, é igual usar chave de fenda com martelo para abrir/quebrar peças de lata/metal ou uma talhadeira em um parafuso para chave de fenda... não vai prestar

[Rodrigo_P_A]

Entendo a visão, mas a Microsoft diz que pode ser usada em IoT https://docs.microsoft.com/pt-br/dotnet/core/

O IoT da Microsoft deve ser um dispositivo com uns 512MB de RAM.

Obrigado pelos comentários.

[chipselect]

Pode ser usado com 512MB sim, uso no Beaglebone Black sem problemas, só fica um pouco lento por causa do clock de 1GHz que é single core, mas rodo NGINX + MONO (ASP.NET MVC) + PostgreeSQL + Node.JS + serviços instalados e rodando em background (obviamente o Beaglebone foi para testes, o servidor que utilizamos é x64 mesmo pois NET CORE 3 não tinha para 32 bits).

O primeiro acesso leva alguns consideráves segundos em uma página quando não está carregado no servidor, mas depois disso fica instantâneo, mas sem chance de rodar com menos de 512MB, pois há algumas funções que batem praticamente 100% de memória quando estamos processando. Detalhe: não é um app HELLO WORLD, mas uma aplicação em ASP.NET MVC com pelo menos 500 mil linhas de código fonte, então seu Hello World com meia dúzia de linhas de código e consumindo 400MB de RAM e minha aplicação com mais de 400 mil linhas adicionais de código tem um acréscimo máximo de 100MB (irreal porque uso ORM gerenciando listas de dados, que pega boa parte da RAM!).

Analisando forçadamente dessa forma (e de forma errado, é claro, pois não se está considerando nada, só por cima mesmo), se fosse fazer a conta, cada linha de código a mais não acrescenta quase nada no uso de memória RAM...

Agora, se for fazer uma aplicação pequena ou demasiadamente simples, talvez seja melhor usar C/C++ mesmo.

[Rodrigo_P_A]

Você rota o banco na placa + o sistema WEB?

[eletroinf]

Como usuário eu vejo que essas linguagens estocadoras de bytes resolvem o problema dos desenvolvedores de conseguir produzir mais e empurram a bomba pro usuário, que deve arcar com sistemas robustos e aguentar a lentidão.
Me lembro bem da interface de um discador de modem 3G que eu tinha... era em .NET, horrível de pesada e não tinha como usar o bendito modem sem abrir aquela M* só pra clicar no "Conectar".
Fora alguns programinhas em java, que se arrastam pra abrir.
Mas isso é a minha visão de usuário.

[Rodrigo_P_A]

Como usuário eu vejo que essas linguagens estocadoras de bytes resolvem o problema dos desenvolvedores de conseguir produzir mais e empurram a bomba pro usuário, que deve arcar com sistemas robustos e aguentar a lentidão.
Me lembro bem da interface de um discador de modem 3G que eu tinha... era em .NET, horrível de pesada e não tinha como usar o bendito modem sem abrir aquela M* só pra clicar no "Conectar".
Fora alguns programinhas em java, que se arrastam pra abrir.
Mas isso é a minha visão de usuário.

Pois é... eu concordo.

Respeito a opinião, mas dizer que num dá pra fazer ou gerenciar projetos complexos em C/C++, disso eu discordo totalmente, tenho projeto muito complexo escrito em C/C++ e que funcionam muito bem com poucos recursos.

Se fosse assim, PostgreSQL, Linux, BDS, Windows, etc.. não seriam escritos em C/C++ , mas é somente uma opinião bem simplista.

O intuito desse post foi apenas mostrar a minha visão simplista da coisa, pra mim, dotnet/java, num serve de jeito nenhum.

Me senti tentado em testar, pois pensei que fosse algo mais enxuto, e me enganei.

[chipselect]

Sim, rodo no Ubuntu Server ou Debian Server com PostgreSQL + Server WEB NGINX + Aplicação em ASP.NET MVC + etc, tudo já foi testado no beaglebone black e no Raspbery PI modelo 3 a título de curiosidade.
Lento na inicialização e primeiro acesso, depois fica bem rápido.
Framework de aplicação próprio + uma penca de outros frameworks, não utilizo ORM, prefiro Micro ORM ou Linq2DB. Isso permite tudo ser altamente modularizado, a nível de poder trocar o database somente mudando a string de conexão (desde que o micro ORM ou o Linq2DB tenha suporte). Também basta pegar os binários e jogar no linux ou no windows e praticamente sair rodando.

Daria para trocar o NGINX pelo Apache como web server, mas o NGINX é mais eficiente no uso de RAM. Com o NET CORE, não precisa necessariamente do NGINX pois o NET CORE tem embutido nele o Kestrel, mas usar o NGINX ou Apache te dará mais opções de configurações. Não tive a curiosidade de tentar tirar o Kestrel do NET CORE no x64, acho que nem dá, mas se tivesse uma opção dessas, liberaria RAM.

Em relação ao "peso" de uma aplicação em JAVA ou C#, concordo que facilita para o programador mas pesa para o usuário. Só que tem o detalhe de que, se fosse usado C/C++ em vez desses monstrinhos no desenvolvimento do software, o aplicativo custaria muito mais caro, e com a diferença do valor do software em C/C++ com os feitos em modo "preguiçoso" daria pro usuário comprar um notebook bom e sobraria grana... então é uma relação custo/benefício.

Obviamente uma aplicação que vendesse milhões de cópias por mês compensaria fazer direto em C/C++, mas é difícil adivinhar se uma aplicação realmente terá sucesso comercial ou não, então é melhor fazer um monstrinho em C# ou Java mesmo, e falar que precisa de um pc bom.

Gosto muito do jeitão do C# mas sinceramente, se eu estivesse saindo de aplicações com C/C++ para começar com desenvolvimento WEB ou misto de até tamanho médio, eu usaria PHP com a penca de frameworks que também existe para PHP, e o do momento é o Laravel (low code).

[chipselect]

Outro ponto é que, não é que não dá para gerenciar projetos grandes com C/C++, até dá, mas é custoso, pois só o próprio desenvolvimento com C/C++ é mais custoso, então só vale a pena em projetos grandes que tenham muita demanda e uso, e são justamente os casos citados: PostgreSQL, Windows, Linux... com milhões de instalações novas por mês pelo mundo... Ou seja, como não vale a pena sem retorno comercial, não dá pra fazer, só por filantropia ou open source (casos citados).

Agora pense num ERP feito em C/C++... qual seria seu custo de desenvolvimento? E quantas licenças mensais teria? Algumas coisas podem ser até dez vezes mais rápidas para desenvolver em C#, ou seja, dez vez mais barato se comparar com C/C++.

Olhe esta resposta:
"C# is hands down my favorite programming language. While it may not be as fast, it has constant loads of luxurious features that make life easier, like expression body members, get and set properties, Linq, etc. They’re always adding new things and making it so you can do what used to take 10 lines of code, into 1 line. "
fonte: https://www.quora.com/What-is-the-diffe ... -C++-and-C

Uma aplicação com 1 milhão de linhas de código em C# seria 10 milhões de linhas de código em C/C++... a um tempo de desenvolvimento 10 vezes maior (ok, linhas de códigos não é uma métrica muito bem aceita em software house, mas vamos fingir que não sabemos disso pra simplificar), e uma dor de cabeça de bug muito maior... o valor explode.

Em C# é possível fazer um sistema SaaS médio multi-tenant por uns 700 mil reais. Ficaria em torno de 7 milhões em C/C++. Eu usaria C/C++ muito feliz se vendesse esse sistema igual a Microsoft vende o Windows... mas não vai vender, então, pra eu não falir, vou de C# e boto requerimento do servidor lá na estratosfera (do ponto de vista de quem programa C/C++). Esta é a visão comercial de uma software house, pois não podemos ver somente o lado técnico, temos que ver se é viável também.

Outro dia voltei pra baixo nível e tava programando PIC12 (sem jogar pedras por favor, foi requerimento do cliente), e tava quebrando a cabeça para liberar 1 (UM) byte de RAM. Um programador que estava do meu lado fez uma cara de quem chupou limão ao saber que eu precisava de um mísero byte, pois ele está acostumado com MB pra usar no código...

[Rodrigo_P_A]

Sim chipselect, é mais custoso mesmo, concordo. Mas mesmo assim, acho que não precisaria o dotnet ser tão pesado. Só isso.