Carlos,
Antes de mais nada gostaria de me desculpar caso minha primeira mensagem
tenha soado um pouco ofensiva, não foi essa a intenção.
Em segundo lugar, acho que houve má interpretação de sua parte. Em momento
algum eu disse que a solução consumiria mais ou menos "memória". O que eu
coloquei em questão na solução com streams vs. XML foi relativo à
"performance". E mesmo em relação ao consumo de memória, isso é facilmente
resolvido utilizando-se o método readLine() do objeto BufferedReader.
E por fim, hoje ao reler meu texto, notei que não coloquei o exemplo correto
no trecho de código (acabei copiando e colando o próprio código original do
problema), mas espero que tenha ficado subentendido que eu pretendia
utilizar indexOf, ou um StringTokenizer ou mesmo uma RegExp para separar os
elementos da string em variáveis (o código original que tinha em mente pode
ser encontrado mais ao final dessa mensagem).
Pois bem, voltando ao assunto original, talvez eu não tenha sido muito claro
em minha explanação. Concordo com você que para chegar a uma conclusão real
sobre qual método é mais rápido torna-se necessária uma bateria de testes.
Mas como nenhum de nós até agora fez tais testes nessa massa de dados, temos
que trilhar uma solução teórica.
Vou detalhar aqui um pouco as premissas da qual eu parti para chegar nesse
raciocínio:
a) Um arquivo de dados XML ficará, sem dúvida alguma, muito maior do que um
arquivo TAB delimited. Logo, quantidade TOTAL de bytes que serão carregados
para a memória, checados e "parseados" (a língua portuguesa que me desculpe
por esta aberração) será muito maior na solução XML. Uma vez que qualquer
operação que envolva acesso à memória ou acesso ao disco em um computador
leva uma fração de tempo para ser executada, tudo isso representa perda de
performance.
b) Para uma rotina que busca por um caracter TAB no meio de uma string, a
razão diz que esta deve ser mais rápida do que uma que busque por TAGs
delimitadoras de início e fim dos dados. Não sei de que modo foram
programadas as máquinas virtuais Java, mas me parece óbvio que para qualquer
CPU é muito mais rápido encontrar um caracter em meio a uma string do que
encontrar duas strings (tags de início e fim) em meio a outra string.
c) Um parser XML, além de ter que buscar pelas TAGs delimitadoras, ainda tem
que checar se a estrutura do documento está perfeita e válida (por exemplo,
tags não finalizadas), o que representa um overhead adicional.
d) A solução, como descrevi em meu email anterior, não necessariamente
precisa carregar o arquivo em sua totalidade para a memória. É possível
fazer o processamento dos dados em partes utilizando-se o método readLine()
de BufferedReader ou então controlando-se manualmente um buffer de memória
para ler somente uma quantidade limitada de dados por vez.
Foram essas as premissas que me conduziram a tal raciocínio. Se o java fosse
uma linguagem compilada em bytecodes nativos do processador em que está
sendo executada, eu não teria a menor dúvida de que esse método seria pelo
menos umas 2 vezes mais rápido do que a solução em XML. Todavia, como o Java
roda dentro de uma máquina virtual, existe a possibilidade da solução XML se
equiparar à solução stream por conta de alguma otimização interna feita em
código nativo. Mas ainda assim,acho muito pouco provável essa possibilidade.
Claro que toda essa discussão está tomando um rumo mais acadêmico do que
prático, uma vez que você já disse ter começado a implementar uma solução em
XML. Qualquer uma das 2 soluções vai atender com segurança. Afinal, o grande
gargalo que se tem em um problema desses não é necessariamente a leitura dos
dados do arquivo XML ou do TXT e sim a escrita desses dados, via JDBC, no
banco de dados.
Implementei há poucos dias uma solução XML para inserir 8.000 registros em
um banco Oracle. Não tenho o que reclamar da performance do parse do XML
(utilizei SAX para tratar os dados). No meu caso específico, optei pelo XML
porque um dos campos de dados era um texto formatado em HTML e com quebras
de linha, o que me impedia logo de cara de utilizar um arquivo somente
texto. Pensei em utilizar serialização de objetos também mas achei melhor
utilizar XML por conta da portabilidade do formato.
Enfim, a solução que propus no email anterior visa basicamente reduzir a
quantidade de reprogramação dos sistemas (tanto dos cliente do servidor) e
aumentar a performance, em detrimento da portabilidade. Porém se tempo (quer
seja de desenvolvimento, quer seja de processamento) não é um problema, opte
sem dúvida por XML, pois a portabilidade vale a pena.
{}'s
David Rissato Cruz
PS: Segue abaixo o código que tinha em mente:
(...)
import java.util.*;
import java.io.*;
(...)
public void leDadosDoArquivo(String nomeArquivo) {
// Define caracter delimitador, no caso TAB
final String delimitador = " ";
// Define variáveis
BufferedReader br;
String linha;
try {
// Cria buffered reader a partir de um FileReader do arquivo
desejado
br = new BufferedReader(new FileReader(nomeArquivo));
while ( (linha=br.readLine()) != null) {
// Quebra a linha em parâmetros baseado no delimitador (TAB)
StringTokenizer st = new StringTokenizer(linha, delimitador);
// função hipotética que recebe o valor de 4 bancos e insere no
banco
//insereValoresNoBanco(st.nextToken(), st.nextToken(),
st.nextToken(), st.nextToken());
System.out.print(st.nextToken() + " <-> ");
System.out.print(st.nextToken() + " <-> ");
System.out.println(st.nextToken());
}
br.close();
}
catch (IOException e) {
System.out.println("Ocorreu um erro na leitura do arquivo " +
nomeArquivo);
}
}
-----Mensagem original-----
De: Carlos Santiago [mailto:[EMAIL PROTECTED]]
Enviada em: segunda-feira, 3 de fevereiro de 2003 07:50
Para: [EMAIL PROTECTED]
Assunto: [java-list] JAVA e XML
Olá a todos.
Está interessante a discussão sobre o uso de XML e JAVA
para o porcessamento de arquivos TXT que havíamos
proposto um tempo atrás.
Das opiniões que li, parace concenso de que o uso de XML
pode diminuir a carga de processamento e o consumo de
memória. A excessão do David que não "entendeu" por que
iria consumir menos memória, a explicação que tenho
colhido da literatura é que diferente da classe File que
carega o arquivo inteiro para a memória para processá-lo
a API de XML carrega apenas o DOM e não o seu conteúdo,
o que torna mais leve o consumo de memória. Mas isso tem
que ser passivo de teste.
Eu tenho trabalhado nesta questão e já desenvolvi uma
DTD e um arquivo XML de exemplo e vou processá-lo usando
o JDOM 0.8 beta. Tenho, também, desenvolvido uma
documentação sobre o assunto (está na versão 0.3 e tem
25 páginas em TXT), se alguém que está participando da
discussão quiser dar uma olhada neste material me avise
e eu mando o material.
Abraço
Carlos
--------------------------
Carlos Santiago
Programador JAVA
Equipe de implementação
Secretaria de Fazenda - MT
--------------------------
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
