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]
-------------------------------------------------------------------------
