É com humildade que venho apresentar a vocês a bibliotéca que criei: Reflector.
Como é de se adivinhar, o Reflector é uma biblioteca que criei para facilitar a utilização do Reflection API.
Ao desenvolve-la, tive como foco facilidade de uso e performance.
[quote=Mikhas][quote=j0nny][quote=Marky.Vasconcelos]1° No site se chama Refractor e voce apresenta como Reflector??
2° Como voce deixou mais rapido que a propria API de Reflection? Voce usa alguma bytecode lib?[/quote]
Minhas pergunta é a mesma da segunda do Marky :lol: [/quote]
1º Mudei o nome da biblioteca mas não consegui renomear a pagina
2º Utilizo javassist e algumas funções internas da JVM e do JDK quando possivel ;)[/quote]
Será que com a Dalvik do Android o desempenho será tao satisfatório assim também?
Pois estou quase liberando a primeira versão do AndOrm, com as funções básicas.
PS: Pq não coloca no GitHub? Fica mais fácil e legal do pessoal contribuir
[quote=j0nny][quote=Mikhas][quote=j0nny][quote=Marky.Vasconcelos]1° No site se chama Refractor e voce apresenta como Reflector??
2° Como voce deixou mais rapido que a propria API de Reflection? Voce usa alguma bytecode lib?[/quote]
Minhas pergunta é a mesma da segunda do Marky :lol: [/quote]
1º Mudei o nome da biblioteca mas não consegui renomear a pagina
2º Utilizo javassist e algumas funções internas da JVM e do JDK quando possivel ;)[/quote]
Será que com a Dalvik do Android o desempenho será tao satisfatório assim também?
Pois estou quase liberando a primeira versão do AndOrm, com as funções básicas.
PS: Pq não coloca no GitHub? Fica mais fácil e legal do pessoal contribuir [/quote]
Creio que no Android ele não utilizará as features “mothafocka” deixando a performance semelhante a da API padrão.
É que eu já uso SVN e estou acostumado. Sem falar que uso Windows.
[quote=Mikhas][quote=j0nny][quote=Mikhas][quote=j0nny][quote=Marky.Vasconcelos]1° No site se chama Refractor e voce apresenta como Reflector??
2° Como voce deixou mais rapido que a propria API de Reflection? Voce usa alguma bytecode lib?[/quote]
Minhas pergunta é a mesma da segunda do Marky :lol: [/quote]
1º Mudei o nome da biblioteca mas não consegui renomear a pagina
2º Utilizo javassist e algumas funções internas da JVM e do JDK quando possivel ;)[/quote]
Será que com a Dalvik do Android o desempenho será tao satisfatório assim também?
Pois estou quase liberando a primeira versão do AndOrm, com as funções básicas.
PS: Pq não coloca no GitHub? Fica mais fácil e legal do pessoal contribuir [/quote]
Creio que no Android ele não utilizará as features “mothafocka” deixando a performance semelhante a da API padrão.
É que eu já uso SVN e estou acostumado. Sem falar que uso Windows.[/quote]
Ah ok, então nem valeria a pena. MASSS, vou fazer um teste a parte mais tarde para comprovar :lol:
Tbm usava SVN e Windows, agora uso Ubuntu e GitHub para projetos pessoais, e Ubuntu e SVN profissionalmente.
[quote=Mikhas][quote=j0nny][quote=Mikhas][quote=j0nny][quote=Marky.Vasconcelos]1° No site se chama Refractor e voce apresenta como Reflector??
2° Como voce deixou mais rapido que a propria API de Reflection? Voce usa alguma bytecode lib?[/quote]
Minhas pergunta é a mesma da segunda do Marky :lol: [/quote]
1º Mudei o nome da biblioteca mas não consegui renomear a pagina
2º Utilizo javassist e algumas funções internas da JVM e do JDK quando possivel ;)[/quote]
Será que com a Dalvik do Android o desempenho será tao satisfatório assim também?
Pois estou quase liberando a primeira versão do AndOrm, com as funções básicas.
PS: Pq não coloca no GitHub? Fica mais fácil e legal do pessoal contribuir [/quote]
Creio que no Android ele não utilizará as features “mothafocka” deixando a performance semelhante a da API padrão.
É que eu já uso SVN e estou acostumado. Sem falar que uso Windows.[/quote]
Dá pra usar sossegado o GitHub usando TortoiseGit. Só muda mesmo o estilo, que é um pouco diferente do SVN.
Boa iniciativa! Não achei que o Mirror estivesse com a performance tão ruim para reflection. Você pode disponibilizar o benchmark para eu dar uma olhada? O problema deve estar no lookup do método.
De qualquer forma parece que está bem simples de usar. Gostei da API (Tirando que o acesso a ela é via métodos static, mas se seu foco é performance, acho que faz sentido.)
Algumas perguntas porque ainda não tive tempo de olhar bem o código
1 - É Thread-safe?
2 - Os truques para acelerar envolvem sun.misc.Unsafe e sun.reflect.*Accessor? Ou você encontrou algo ainda mais baixo?
3 - Javassist para analize do bitecode certo? Você chegou a medir os ganhos de performance? Eu estava pensando em fazer isso pro Mirror, mas se já tiver dados melhor ainda
Boa iniciativa! Não achei que o Mirror estivesse com a performance tão ruim para reflection. Você pode disponibilizar o benchmark para eu dar uma olhada? O problema deve estar no lookup do método.
De qualquer forma parece que está bem simples de usar. Gostei da API (Tirando que o acesso a ela é via métodos static, mas se seu foco é performance, acho que faz sentido.)
Algumas perguntas porque ainda não tive tempo de olhar bem o código
1 - É Thread-safe?
2 - Os truques para acelerar envolvem sun.misc.Unsafe e sun.reflect.*Accessor? Ou você encontrou algo ainda mais baixo?
3 - Javassist para analize do bitecode certo? Você chegou a medir os ganhos de performance? Eu estava pensando em fazer isso pro Mirror, mas se já tiver dados melhor ainda :)[/quote]
Não fiz testes com varias threads, só testes funcionais, mas acredito que tem haverá muitos problemas pois os proxies possuem em sua maioria atributos finais.
Eu utilizo o Unsafe quando possivel e o javassist para criar proxies também. Não o utilizei para analize de bytecode já que nunca vi isso na vida… mas esta ai uma coisa para correr atrás.
O teste de performance que fiz é bem simples na verdade: ReflectorPerformanceTest
Tentei ser o mais just possivel com todas as API’s.
O tópico está duplicado. Há outro igual no sub-forum para projetos brasileiros.
A iniciativa é boa, a documentação está bem clara e tem uma boa wiki (bem simplese direta).
Mas não gostei de ter uma javassist embedded por dois motivos: o jar fica grande, e isso pode ocasionar classloader hell caso o usuário tenha outra versão do javassist. Meu conselho é não usar assim ou renomear de javassist.* para br.mikhas.reflector.*, que é o que o pessoal faz quando distribui coisas embedded.
Na classe principal há um map que guarda um cache dos proxies criados pelo Javassist. É bom cuidar com essas coisas staticas, pois não são thread-safe.
Eu fiquei mesmo impressionado com o gráfico. Ser mais rápido que o Mirror ou outra lib semelhante pode ser, mas ser mais rápido que o JDK, só se usar cache. Mas isso por outro lado é perigoso por causa do acumulo de memoria e também com o cuidado de guardar esse cache thread-safe.
Usando classes internas da VM dá pra ser consideravelmente mais rápido que a VM pois você consegue ignorar várias checagens de segurança. Além de que no caso de fields, você consegue acesso direto à memória usando o sun.misc.Unsafe.
Usando classes internas da VM dá pra ser consideravelmente mais rápido que a VM pois você consegue ignorar várias checagens de segurança. Além de que no caso de fields, você consegue acesso direto à memória usando o sun.misc.Unsafe.[/quote]]
Hmm, muito interessante. Eu ví isso se não me engano no Objenesis, onde há algumas implementações usando recursos internos específicas das VMs.
Usar sun.misc não é portavel infelizmente. Nao vai funcionar no openjdk, por exemplo. E provavelmente tambem nao na jvm da IBM… haverá ClassDefNotFoundError.
Mas existem bibliotecas que encapsulam essas chamadas especificas, assim como o XStream e o Objenesis fazem. Ai fica “seguro”.
Usando classes internas da VM dá pra ser consideravelmente mais rápido que a VM pois você consegue ignorar várias checagens de segurança. Além de que no caso de fields, você consegue acesso direto à memória usando o sun.misc.Unsafe.[/quote]
Jonas, deve ser bem facil mudar a implementacao pra ficar mais rapido, mas acho ate um pouco desnecessario na maioria absoluta dos casos: a diferenca de gastar 1 nano segundo e 10 nanosegundos, numa operacao que só faremos 1 vez num request web, é mais que negligenciavel. Prefiro que continuem utilizando a reflection pura e mantenha compatibilidade da maneira simples.
Bom, nada impede que essas próprias bibliotecas para facilitar reflection encapsulem essa lógica, como fiz no Mirror com o reflection provider específico para a VM da Sun.
Concordo que para uma requisição web é o ganho é praticamente desprezível mas não sei se todos os casos de uso de reflection se encaixam aí, em especial se essa otimização estiver bem encapsulada.
Po, se conseguirem deixar isso portavel sem a VM da Sun, eu usaria no Towel, tem bastante Reflection lá, usar algo mais rapido seria interessante. Mesmo que no momento seja inperceptivel o tempo que leva, acho razoavel utiliza-la.
Tomei o cuidado que pudi para a biblioteca verificar qual a melhor implementação utilizar dependendo do que estiver disponivel no ambiente.
Se nenhum “recurso avançado” estiver disponivel, ela vai utilizar a implementação padrão da JDK.
Pretendo correr atrás de outras optimizações ainda que possam ser utilizadas em outras plataformas.
Basicamente o problema é que acelerar reflection com coisas específicas de VMs exige praticamente um código para cada VM. Mas provavelmente na maioria delas é possível escrever código assim. Mas na prática, com a quantidade de gente que usa a VM da Sun, um speedup para essas VMs já pode ajudar seus usuários.
Mas otimização precoce é a raiz de todos os males. Veja se realmente vale a pena migrar seu código para receber ganhos que praticamente só aparecem com o uso bem intensivo de reflection.
(Tirando que o acesso a ela é via métodos static, mas se seu foco é performance, acho que faz sentido.)