Péssimo experiencia com groovy
03/05/2013 14:56
1
Já estou lendo meu segundo livro de groovy e todos eles pontuam bastante a verbosidade de código da linguagem Java. Muito bem...nos meus primeiros 10 minutos Groovy descobri que existe um bug (http://jira.codehaus.org/browse/GROOVY-1875) que faz com que qualquer classe groovy executar métodos privados de outras classes. Ou seja, encapsulamento e isolamento que é a base de tudo de uma arquitetura vai para o lixo.

Gostaria de opinião de alguém que já tem adotado groovy em produção...porque na minha modesta opinião (como tomada de decisão de tecnologia) algo que me impede de adotar.

Alguém?
Tags: Bug Critico no Groovy


2
Oi Fernando,

eu adotei Groovy em produção diversas vezes e em todas elas foi sucesso. No caso, estou observando que este bug é de 2007 da versão 1.1 da linguagem (estamos na 2.0 hoje).

Na prática, este nunca me trouxe problema algum, porque se o método é privado, nós simplesmente não os chamamos a partir do objeto cliente: não faz sentido. É interessante observar que não chega a ser um bug tão sério assim porque, se assim fosse, o mesmo poderíamos dizer da reflexão padrão do Java que também nos permite fazer a mesma coisa (método setAccessible(true)) por exemplo.

A arquitetura vai toda para o ralo é quando nós começamos a desrespeitar algo definido no nosso código. Veja a situação que você cita, por exemplo: por que diabos alguém da sua equipe iria querer executar métodos privados de outra classe? Supondo que quisesse, não seria uma daquelas situações nas quais valeria à pena repensar a própria interface da classe na situação em questão?


0
Obrigado pela resposta...é justamente oque eu penso! Via reflexão é possível furar atributos e métodos privados...mas tem que fazer muito código e tratar muita exception para fazer-lo. Ja com esse bug 100% escancarado, eu posso até dizer que estimula os programadores a faze-lo.
Mas não chega ser um grande problema não...

Outra pergunta Henrique.
Como ta questão de performance do grovvy? Em todo lugar que vc vai, todos falam a mesma coisa, que o complemento que o groovy traz em cima da linguagem Java + JDK + a parte dinâmica resulta em execução ruim.

Como eu estou estudando e avaliando para adoção....eu fiz testes hoje mesmo com JDK7 e Groovy 2.0 e pude comprovar realmente tem uma média de 100% mais lento...do que java puro.
Essa versão 2.0 ja usa a invokedinamic?

O que vc pode comentar sobre esse fato?
03/05/2013 19:40


1
Oi Fernando,

com relação à performance, o que posso te dizer com muita segurança é que pra mim nunca foi problema. E trabalho com Groovy/Grails desde 2007, 2008. Na realidade, quando é problema, normalmente tá no código Java OU algum vacilo que cometi (normalmente inclusive a culpa é minha).

O Groovy 2.0 por exemplo tem uma performance muito próxima da do Java, então o custo que você vai ter não é tão grande assim ao ponto de inviabilizar um projeto. O pessoal se esquece de um detalhe: Groovy gera bytecode, e o bytecode é otimizado pelo JIT assim como rola no caso do Java. Pode haver algum overhead na parte que lida com meta programação, mas numa boa? Nestes casos você usa este recurso da linguagem com maior cuidado.

O Grails Brasil mesmo é um bom exemplo de performance: os tempos de resposta são muito bons, e nosso consumo de memória é mínimo (minha instância tem 612 Mb de RAM, uso algo em torno de uns 300, 400Mb com muitos usuários logados).

Sobre performance, é o tal negócio: depende do contexto pra inviabilizar uma tecnologia. Se for um CRUD, tanto faz se a coisa é feita em C, Java, Groovy, Lisp, etc. Se é para um processamento em lote brutal, tem de ver até se vai ser em linguagem de alto nível dependendo do caso. :)

Tem de ter muita atenção com os benchmarks que a gente vê por aí e também com os que a gente faz. A maior parte são inúteis e não dizem nada. Por exemplo: testes com fatorial ou meramente numéricos. Ok: ótimo para uma aplicação que lide com matemática bruta, mas e para uma que lide com processamento em lote? Eu costumo validar a linguagem/ambiente com provas de conceito próximas do que vou fazer por causa disto. (ninguém em sã consciência no dia a dia faz aqueles loops de 10000000000 de iterações somando coisas ou executando bubble sort :D)


0
Obrigado pela resposta.

Fizemos uns benchmarks aqui transformando algumas classes java de alguns projetos Java em Groovy 2.1 rodando em ambiente de homologação e tivemos pudemos comprovar Groovy fica mais lento a cada instrução dinâmica acrescentada, em torno de 50%, 100% e 150%.

Eu realmente não sei o que fazer, concordo que as facilidades da linguagem são incríveis....estou louco para usar.....mas parece que o preço ainda esta ficando caro. Vamos ver....

Obrigado até aqui..
03/05/2013 21:00


0
Oi Fernando, saquei.

Sugiro que você experimente minimizar estas chamadas dinâmicas. Na boa? Estas chamadas dinâmicas normalmente não são tão vitais assim.

Lembre-se de que você terá problemas semalhantes com todas as outras linguagens alternativas da JVM. É sempre assim: elas nos oferecem algo de um lado e tiram um pouco da outra. A questão é medir se o ganho que você vai ter para o problema compensa ou não.

Qualquer coisa, já sabe: to aqui pra te ajudar ok?


0
Sigo uma estratégia que talvez lhe ajude.
Adoto um modelo de desenvolvimento poliglota. Para coisas que requerem mais performance, uso Java ou outra coisa qualquer. Para o resto, Groovh, Clonure, etc.

Com isto eu ganho o melhor dos mundos: uso o forte das linguagens aonde elas se aplicam e evito pagar um preço muito alto por ter apostado todas as minhas fichas em uma solução única.


0
Eu entendo sim. Segue meu plano para o grovvy:

- Vou terminar meus estudos na linguagem para absorver todos os recursos.
- Vou alterar para groovy o projeto de validação de "prova arquitetural" que é a base do do desenvolvimento da empresa que usa JSF, Spring, JPA, JTA, Tomcat7 e SQLServer
- Nessa alteração, eu vou usar tudo do groovy (GroovyBean, GDK e Clousure) que eu precisar para facilitar o desenvolvimento que é justamente a motivação de adotar groovy - escrever bem menos e ter maior produtividade na equipe.
- Vamos fazer um benchmarks do tempo de desenvolvimento. O quanto fomos mais produtivos com groovy?
- Esse projeto já tem os casos de teste unitarios com jUnit e testes de carga e stress usando jMeter. Vou simular carga boa e obter as medias de tempo de resposta para o usuário final.
- No final de tudo isso, terei um estudo completo me dizendo o tempo de desenvolvimento/produtidade ganho usando o groovy + a queda de performance em testes unitários e testes reais de stress por adotar uma linguagem dinâmica.

Eu vou criar um post no meu blog com estas informações e volto aqui para compartilhar.
Obrigado Kiko até aqui pelas respostas.
04/05/2013 12:54


3
Olá, Fernando.

Fiz um trabalho no qual tentei ser o mais imparcial possível comparando o desempenho do JBoss Seam e do Grails. O Grails se saiu bem melhor em quase todos os casos. Nos cenários onde o Seam foi melhor a vantagem foi bem pequena. O trabalho foi publicado na GroovyMag ano passado: http://www.groovymag.com/main.issues.description/42

Abraços.


1
Legal..não sabia que existia revista de groovy.
Vamos ver oque vai dar...
06/05/2013 11:52


0
Mais que a revista sobre Groovy: um artigo FODA de um brasileiro SENSACIONAL que é o José Yoshiriro representando a gente no exterior (e muito bem por sinal!). :)



0
Oi Fernando Franzini vi no seu blog que vc esta ate ministrando treinamento de groovy, vc poderia descrever agora quase 2 anos depois a sua visão sobre o groovy 
30/11/2015 15:54


0
Sobre a questão do encapsulamento, normalmente atributos privados não são documentados. Você não chama um método privado "sem querer", se você faz isso ou você sabe muito bem o que está fazendo, ou está sendo irresponsavel e tem que se dar mal mesmo.

Sobre performance, vocês já descompilaram uma classe groovy? O compilador gera muito lixo para suportar o aspecto dinamico da linguagem (e ele precisa fazer isso MESMO se você não usa nenhum recurso de meta programação). O JIT não faz isso sumir por milagre, você continuará tendo um codigo ineficiente, só que rodando nativamente (o que é menos pior). Agora, concordo que muitas vezes isso não faz diferença alguma, e quando você estiver numa situação em que REALMENTE o código groovy ficar pesado você pode usar @CompileStatic que acredito fazer o compilador gerar um código mais limpo (abrindo mão de certos recursos da linguagem, logicamente) ou então reescreve aquela classe em Java, ou mesmo em C


0
Magno, sobre desempenho.
Um dos nossos clientes tem uma API Groovy que executa 1.000.000 de transações por minuto.

Sobre o código "lixo", discordo: se você ler vai ver que todo ele é necessário. E quantidade de código não implica perda de desempenho. 
Exemplo clássico: quick sort é ordens de magnitude mais rápido que o de seleção, e o código é bem maior.
E no caso do Groovy e outras linguagens dinâmicas, você deve levar em consideração também a instrução invokedynamic que, já faz alguns anos, praticamente resolveu estes problemas de desempenho.


0
Kico,
Respeito o enorme conhecimento que você sempre demonstra ter, mas infelizmente noto neste e em outros posts que quando se trata de opiniões diretamente sobre Groovy e Grails você tende a ser um tanto passional.. Fica a dica para você refletir sobre isso.

Agora, o que estou tentando explicar é que para suportar todos os recursos da linguagem, o compilador gera uma tonelada de código a mais, que obviamente tem um custo em termos de tempo de execução. Não é sábio fingir que isso não existe, porém, como eu disse anteriormente, frequentemente isso acaba sendo um fator de menor relevância.

Nunca analisei a produção do compilador quando este se vale do invokedynamic, mas mesmo na documentação oficial da linguagem é dito que isso no máximo te leva a uma performance próxima da obtida com Java puro

Resumindo: Você nunca vai conseguir em Groovy a mesma performance que pode conseguir em Java, assim como neste você nunca conseguirá a mesma performance que conseguiria em C por exemplo, devido aos overheads inerentes a cada tecnologia, não existe milagre. O programador deve ser sábio o bastante para colocar isso na balança junto com as demais vantagens e desvantagens de cada tecnologia para uma determinada  tarefa.


1
Magno,
Apenas apresentei dois fatos. Se você chama isto de passionalidade, é um conceito pessoal seu bastante interessante do termo. 
Sobre dizer minha passionalidade, aconselho você primeiro me conhecer melhor antes dizer este tipo de coisa, pois averiguando verá que é o exato contrário. 
Novamente, sobre desempenho, a grande questão é e deve ser sempre a seguinte: qual o seu requisito de desempenho?
Groovy no geral sempre será mais lento que Java por uma razão simples: vencer o Java neste quesito nunca foi o objetivo dos projetistas e, sinceramente, dado que nunca foi um dos objetivos, termina por por a questão do desempenho envolvendo a linguagem no mesmo patamar que o argumento de que facas são ruins por que se barbear com elas é perigoso,


0
Um post sobre Performance: Grails vs. Java,
http://kentbutlercs.blogspot.com.br/2013/02/grails-vs-java.html
05/12/2015 20:30



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto