Alguém pode me explicar o porque java foi mais rápido nestes testes no clean mode?
Motion Compensation time
Frame Capture time
Image Preprocessing
Output Display time
Video Stabilization time
[quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).
[/quote]
A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.
E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)[/quote]
Se você usar o driver da Oracle está usando jni.
Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.[/quote]
o thin driver da oracle é java puro.
[quote=bobmoe][quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).
[/quote]
A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.
E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)[/quote]
Se você usar o driver da Oracle está usando jni.
Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.[/quote]
o thin driver da oracle é java puro.[/quote]
Melhor ainda;
Mas quando eu disse “da Oracle” estava me referindo ao “MySql”. Mas não sei também se ele possui um driver java, o que eu conheço é nativo.
O hotspot já otimiza o bytecode e o compila para código de máquina, então na maioria dos casos jni é insignificante para ganhos de desempenho. É mais útil para a integração com bibliotecas nativas já existentes. O Artigo no post anterior explica isso.
[quote=juliocbq][quote=bobmoe][quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).
[/quote]
A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.
E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)[/quote]
Se você usar o driver da Oracle está usando jni.
Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.[/quote]
o thin driver da oracle é java puro.[/quote]
Melhor ainda;
Mas quando eu disse “da Oracle” estava me referindo ao “MySql”. Mas não sei também se ele possui um driver java, o que eu conheço é nativo.
O hotspot já otimiza o bytecode e o compila para código de máquina, então na maioria dos casos jni é insignificante para ganhos de desempenho. É mais útil para a integração com bibliotecas nativas já existentes. O Artigo no post anterior explica isso.[/quote]
acho difícil drivers jdbc atuais terem código nativo, já que os deste tipo não são thread safe (tipo II).
[quote=bobmoe][quote=juliocbq][quote=bobmoe][quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).
[/quote]
A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.
E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)[/quote]
Se você usar o driver da Oracle está usando jni.
Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.[/quote]
o thin driver da oracle é java puro.[/quote]
Melhor ainda;
Mas quando eu disse “da Oracle” estava me referindo ao “MySql”. Mas não sei também se ele possui um driver java, o que eu conheço é nativo.
O hotspot já otimiza o bytecode e o compila para código de máquina, então na maioria dos casos jni é insignificante para ganhos de desempenho. É mais útil para a integração com bibliotecas nativas já existentes. O Artigo no post anterior explica isso.[/quote]
acho difícil drivers jdbc atuais terem código nativo, já que os deste tipo não são thread safe (tipo II).[/quote]
Existem muitas coisas que não são thread safe, uma delas é o próprio swing, e ele é completamente escrito em java. Isso não tem nada a ver com a conversa de desempenho de aplicações.
Eu fiquei com uma dúvida…
Esse driver atual do mysql padrão na sua release é nativo ou não?
[quote=bobmoe]
acho difícil drivers jdbc atuais terem código nativo, já que os deste tipo não são thread safe (tipo II).[/quote]
O mysql também é java. Tem razão.
[quote=quebrado]Aqui onde trabalho temos um grande volume de informações e muitos calculos horarios.
E o negocio é demorado. Gostaria de procurar algo que nos ajude a fazer processamentos batch mais rapidos.
Tem processamento nosso que demora mais de 12 horas. 
[/quote]
resolvido mano, se o processamento é lento esta ai as causas.
:arrow: base de dados
carrega e processa os dados e envia para a memoria
:arrow: linguagem de programacao
recebe os muitos dados e calcula o que for necessario e depois volta a enviar para a base de dados onde é guardado e ou recebido os outros dados a anlisar.
solução:::::
para os calculos mais complexos e demorados usa sempre procedures do lado do servidor de base de dados (oracle pl/sql).
assim os dados sao carregados e analisados todos dentro do banco de dados, e acho que fica 50% mais rapido
[quote=kicolobo]Olha, vou contar uma coisa.
Eu já vi empresa QUEBRAR porque trocaram sistema legado “antiquado” em COBOL ou VB6 por algo feito em Java. Java é do caralho? Sem dúvida. É a minha plataforma favorita, mas não é ideal pra tudo.
Aliás, esta onde de “substituir o legado” de cara, na minha opinião, duas coisas:
- Falta de respeito total com o investimento anterior feito pelo seu cliente.
- Irresponsabilidade movida a arrogancia (e a arrogancia é alimentada pelo que? Ignorancia)
Eu já vi software de tempo real, que controla industria, feito em VB6.
Já vi gerenciamento de custos bilionários feito em Access 97 e Excel
Já vi softwares de empresas multi bilionárias feitos em FoxPro que funcionam, são mantidos e ampliados até hoje.
Muita coisa de engenharia feita em Fortran que é insubstituível
E muita coisa impressionante em COBOL
Vai trocar, vai. Da merda. Não porque a tecnologia é boa ou ruim, mas porque foi usado algo que, para o caso, caia como uma luva.
O Joel Spolsky tem um texto ótimo sobre esta questão: http://www.joelonsoftware.com/articles/fog0000000069.html
Aliás, sobre COBOL, eu fiz uma pesquisa a algum tempo atrás. Os resultados foram surpreendentes pra mim na época: http://www.itexto.net/devkico/?p=135
[/quote]
“”"" o segredo não esta na arma, mas sim no ninja ( shinobi ) “”""
traduzindo “”"" o segredo não esta na linguagem , mas sim no programador “”"
o problema do java é o tempo de estrada, para os mais velhos e programadores mais experientes ( a partir dos 50 anos acima ), dificilmente usam java, e se usarem não conhecem a linguagem a fundo, porque java é uma tecnologia recente, tem poucos anos de estrada, e normalmente os mais velhos e experientes programadores, é que lideram os grandes projectos, e sempre preferem apostar nas linguagens da idade da pedra, até que alguem les prove o contrario eles vao achar que java nao é melhor que as linguagens antigas cobol e etc, mas sem esquecer dois pontos essenciais, para cada projecto podera ter uma linguagem que mais se adequa ao caso.
[quote=kicolobo][quote=s4nchez]Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.
Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.[/quote]
SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.[/quote]
o problema não esta na linguagem orientada a objectos, o problema esta na pessoa que programa orientado a objectos…
depende da plataforma, o java rodando em mainframe com vm otimizada suporta o volume do que voce imaginar. mas depende mais da otimização em hardware, cobol é feito pra rodar em mainframe é por isso, java sempre foi utilizado em baixa plataforma. sao conceitos diferentes.
[quote=dmitsuo]Pessoal, eu estava num treinamento em Brasília esses dias e o instrutor disparou essa pérola:
Bem, nem precisa falar que na mesma hora ele foi contestado. Primeiro que paradigma de desenvolvimento não tem nenhuma correlação direta, em princípio, com performance, e depois grande parte dos sistemas dessa área ainda são legados (penso eu), e por isso ainda são sistemas do tempo da análise/projeto estruturado, orientados a dados, ou até mesmo são do tempo que nem existia qualquer tipo de paradigma 
Mas mesmo assim fiquei com a pulga atrás da orelha. Será que esses bancos da vida, os maiores pelo menos (BB, Caixa, Bradesco, Itaú), ainda não têm mesmo seus sistemas de missão crítica desenvolvidos sob o paradigma da orientação a objetos por algum motivo relacionado a performance?
Tem alguém aqui no Fórum que trabalha, ou trabalhou, em algum desses bancos pra confirmar, ou refutar, essa tese estapafúrdia, IMHO, do distinto instrutor? É verdade mesmo que os sistemas dos bancos não são O.O. (possivelmente em Java) por questões de performance? Se alguém souber de exemplos de bancos aqui no Brasil ou no exterior para ajudar a desconstruir, ou confirmar, essa tese eu agradeceria.
–[/quote].
pra fechar o topico o ultimo post, :? :?
se isso fosse verdade “”“Sistemas O.O. não são apropriados para grandes demandas (milhares de transações/hora)” “”
então o cobol nao incluiria a versão orientada a objectos.
Acabei de ver um artigo no Javalobby (Java PHP Python - Which is “Faster In General”?) relacionado ao tema aqui do tópico. Não trata especificamente de COBOL vs. Java, mas de Java vs. PHP vs. Python.
Logo de cara esse artigo faz uma afirmação que serve de resposta ao meu ilustre instrutor (excelente profissional por sinal, mas acho que comeu mosca sobre o que falou de Java e OO):
Abraços.
Davi.
[quote=dmitsuo]Acabei de ver um artigo no Javalobby (Java PHP Python - Which is “Faster In General”?) relacionado ao tema aqui do tópico. Não trata especificamente de COBOL vs. Java, mas de Java vs. PHP vs. Python.
Logo de cara esse artigo faz uma afirmação que serve de resposta ao meu ilustre instrutor (excelente profissional por sinal, mas acho que comeu mosca sobre o que falou de Java e OO):
Abraços.
Davi.[/quote]
Mas a discussão não era sobre linguagem, era sobre o paradigma da linguagem.
E quando eu aprendi OO na faculdade ouvi muitos boatos que em grandes sistemas, OO não era nada recomendado, mas não tenho nenhum artigo para comprovar isso, então não sei se é verdade.
Eu também acho que os OO não são apropriados, pois usa muito a memória, por isso prefiro as procedurais, além de serem mais rápidas.
Aqui no serviço só trabalhando usando o bom e velho paradigma procedural.
[quote=Forreta]seu professor esta corretíssimo.
Qualquer operação da área da banca ou seguros é feita em AS/400 ou Mainframe.
A Allianz trabalha INTEIRAMENTE com COBOL, tem apenas a interface gráfica feita em .NET, o resto é TUDO cobol!
E quer saber? Funciona melhor do que se fizesse em .NET/Java (coloco os dois porque são duas linguagens iguais)
A Groupama Seguros (uma das maiores seguradoras da europa) trabalha da mesma forma que a Allianz.
O BBVA Madrid é igual.
Java/.NET é ridiculo para sistemas TPS.[/quote]
So um detalhe, .NET nao eh linguagem.
Acho que vc queria comparar C# com Java, ambas tem similaridades, mas o C# tem um monte de coisas que o Java nao tem e vice-versa.
Voltando ao topico, eu nao entendo a raiva que o pessoal aqui desse forum tem com o Cobol e programadores Cobol, eu dou muito mais credito pro tiozao de 50 anos que desenvolveu e implementou um monte de sistemas nos maiores bancos do Brasil e continuam rodando ate hoje do que neguinho de 20 e poucos anos que so faz sisteminha de cadastro usando netbeans “porque eh mais facil pra fazer as telinhas” hehehe
O Cobol eh uma linguagem extremamente robusta e serve muito bem o seu proposito.
Eu trabalhava com bioinformatica uns anos atras, eu tinha que processar muitos arquivos de texto (strings gigantes de DNA) fazia tudo em Perl, um belo dia alguem disse que nos deveriamos fazer em Java, fiz uns testes e adivinha qual atentou melhor o que a gente queria e rodou infinitamente mais rapido? Perl!!! Isso mesmo Perl, linguagem de script. 
Mesmo sendo linguagens completamente diferentes, qual eh melhor??? Perl eh bom pra umas coisas e impossivel pra outras, mesma coisa Java.
Talvez o seu instrutor tenha se expressado um pouco mal o que ofendeu os javeiros de plantao, mas ele tem um pouco de razao sim.
Como ja falaram tem muitas razoes que o Cobol ainda ta por ai e vai ficar por muito tempo, eh o famoso “em time que ta ganhando nao se mexe”, como ja disseram acima.
//Daniel
[quote=bozo25]Eu também acho que os OO não são apropriados, pois usa muito a memória, por isso prefiro as procedurais, além de serem mais rápidas.
Aqui no serviço só trabalhando usando o bom e velho paradigma procedural.[/quote]
Em que linguagem ??? :shock:
sim, GWT.
sim. era .Net, mas migrou pra java. aqui no guj tem um tópico sobre. 
pode ser que eu me engane, mas acho que é só C++
sim, só tem ‘ninja’ lá, com um tesão enorme por Python e AJAX… alguém me disse que eles tem uma espécia de ‘white papers’ online, onde é possível saber o que eles usam, em cada sistema etc, mas esqueci a url… :roll:
aí eu já não sei…
eu fico pensando se a limitação é mesmo o java.
penso em sistemas horizontalmente escalaveis, cache, rest, map reduce e seria possivel rodar em uma cloud um sistema eficiente que capaz de processar qq coisa - principalmente elastico para aguentar o pico. provavelmente falamos de processamento onde precisamos cruzar tantas informações que precisamos de tecnicas elaboradas e o cobol esta ai, faz de uma forma menos complexa, etc…
Pessoal, à propósito do assunto, olha o que o Mike Cohn escreveu no site dele. Ele tá falando de outro assunto nesse post, dos dez anos do manifesto ágil, mas fez uma analogia mencionando justamente o tema discutido aqui na thread.
Bem, vindo de um cara renomado como ele, acho que tem um peso enorme nessa discussão:
O texto completo (excelente, por sinal) vocês podem conferir aqui: Reflections on the 10 Years Since the Agile Manifesto (http://blog.mountaingoatsoftware.com/reflections-on-the-10-years-since-the-agile-manifesto)
Aos que se manifestaram aqui na thread, meus agradecimentos por me deixar por dentro das mais diferentes visões e circunstâncias sobre esse assunto. Valeu!
Bem, cheguei atrasado, mas vou dar o meu pitaco:
A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.
Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.
Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:
[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]
Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.
OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.