Nesse caso existe um trade-off entre desempenho e facilidade para escrever o código, já que alguns dos padrões usados para implementar algumas funcionalidades possuem algum custo computacional na sua execução. Porém as vezes é necessário pagar esse custo devido a característica do problema a que está sendo resolvido. Saber escolher quando esse custo deve ser pago, ou pode ser pago sem prejuízos é de grande valor para alguns sistemas. A ideia dessa série é mostrar um ponto de vista sobre orientação a objetos como algo que surge de determinados padrões de código, assim como existem outros padrões de código que resolvem certos problemas (como usar uma variável auxiliar para trocar o valor de variáveis, as funções filter, map e reduce para tratar iteráveis...), dando uma visão de como orientação a objetos é implementada e o que determinadas sintaxes descrevem, e se possível uma ideia de custo para implementar esses padrões ou como transitar entre um código estruturado e orientado a objetos.
Eu não sei exatamente o custo de todos os recursos, e também não conheço nenhum material que teria isso. Porém, considerando o caso de funções virtuais da apresentação do autor do htop, sim, esse custo é quase insignificante para um computador atual, porém pode fazer diferença em um hardware mais limitado, como um Arduino, ou em um servidor que execute a mesma função milhões ou bilhões de vezes em um curto período de tempo, onde uma pequena diferença é escalada várias vezes. Hoje se usa Python para fazer diversos scripts, que conhecidamente não tem o melhor desempenho (salve quando utiliza alguma lib implementada em C ou Fortran), então muitas vezes esse custo é pago sem que o usuário final perceba tanta diferença, e acredito que o custo do interpretador do Python seja muito maior do que a implementação de algumas funcionalidades de orientação a objetos. Rust é vendido como uma linguagem que só se paga o custo do que se usa, porém é necessário de um bom conhecimento de baixo nível para entender esses custos.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nesse caso existe um trade-off entre desempenho e facilidade para escrever o código, já que alguns dos padrões usados para implementar algumas funcionalidades possuem algum custo computacional na sua execução. Porém as vezes é necessário pagar esse custo devido a característica do problema a que está sendo resolvido. Saber escolher quando esse custo deve ser pago, ou pode ser pago sem prejuízos é de grande valor para alguns sistemas. A ideia dessa série é mostrar um ponto de vista sobre orientação a objetos como algo que surge de determinados padrões de código, assim como existem outros padrões de código que resolvem certos problemas (como usar uma variável auxiliar para trocar o valor de variáveis, as funções filter, map e reduce para tratar iteráveis...), dando uma visão de como orientação a objetos é implementada e o que determinadas sintaxes descrevem, e se possível uma ideia de custo para implementar esses padrões ou como transitar entre um código estruturado e orientado a objetos.
mas o custo em desempenho neste caso chega a ser insignificante, não? Você tem algum material aí pra gente ver qual seria este custo?
Eu não sei exatamente o custo de todos os recursos, e também não conheço nenhum material que teria isso. Porém, considerando o caso de funções virtuais da apresentação do autor do htop, sim, esse custo é quase insignificante para um computador atual, porém pode fazer diferença em um hardware mais limitado, como um Arduino, ou em um servidor que execute a mesma função milhões ou bilhões de vezes em um curto período de tempo, onde uma pequena diferença é escalada várias vezes. Hoje se usa Python para fazer diversos scripts, que conhecidamente não tem o melhor desempenho (salve quando utiliza alguma lib implementada em C ou Fortran), então muitas vezes esse custo é pago sem que o usuário final perceba tanta diferença, e acredito que o custo do interpretador do Python seja muito maior do que a implementação de algumas funcionalidades de orientação a objetos. Rust é vendido como uma linguagem que só se paga o custo do que se usa, porém é necessário de um bom conhecimento de baixo nível para entender esses custos.