FiveTech Software tech support forums

Mr. Rao,

Muchas gracias por sus tests.
Pues creo que tiene vd. razón.
Yo mismo he hecho mis test sencillos y arrojan tiempos sorprendentemente bajos para ~ 125 mb

Este es mi codigo:


Thank you very much for your tests.
I think you are right
I myself have done my simple tests and throw surprisingly low times for ~ 125 MB

This is my code:

Code: Select all  Expand view

function Data2Csv()
Local nI
Local cLin:= ""
Local cFull:= "\Tmp\articulos"
Local cIni
Local nRecords:= 0
Local nFCount
msginfo("Empezando")

cIni:= Time()

nH:= FCreate(cFull+ ".csv")

select 0
use (cFull)
nFCount:= FCount()
go top
do while !Eof()
   FOR nI:= 1 TO nFCount
      cLin+= Transform(FieldGet(nI), "")+ ";"
      IF nI != nFCount
         cLin+= ";"
      ENDIF
   NEXT
   FWrite(nH, cLin)
   nRecords++
   cLin:= ""
   SKIP
enddo
FWrite(nH, cLin)
FClose(nH)
CLOSE
mMsgInfo("Time End "+ Time()+ CRLF+ "Time Init "+ cIni+ CRLF+;
         "Records "+ Transform(nRecords, "")+ CRLF+;
         "Fields "+ Transform(nFCount, "") )
RETURN NIL

Manuel,

Voy a buscar en mi codigo que cosas estan consumiendo el tiempo.
La rutina de sutff para una cadena estará bien, pero creo que para mi es más importante encontrar donde se ralentiza el proceso realmente.


Gracias a todos por vuestro interés.
Volveré a decir más cuando tenga mas información.

Saludos.

In my view, using (x)Harbour's COPY TO command is the fastest way to produce a CSV file. This command internally uses DBF2TEXT() function written entirely in C and is fairly optimized for the intended purpose.
There is no point in re-inventing the wheel. Even if we want to write a more efficient function, we can not do it with a Harbour level function or mix of Harbour and C level functions. We too need to write the entire function in C and in that case, are very likely to end up with a function similar to DBF2TEXT(). Obviously, the effort is not worth the result.

Bueno parece que Mr. Rao ha dado con la mejor solución para Paquito.
Pero esa no es la solución para algo genérico (no solo DBF) como quiere Carlos. ¿No?

Lo hago o no?

Paquito lo ralentiza la maquina virtual y el recolector de basura.

Mi propuesta sería hacerlo en C con lo que se evitaría dependencias como las que indica Carlos y te garantizo que la memoria no se fragmentaría nada.
Y ademas se podría usar para crear un bufer de escritura a un fichero cuya entrada podría ser cualquier cosa y no solo una DBF.

Yo lo hago si hace falta, si no, no...

Como dijo alguien: "Si hay que ir se va, pero ir pa ná..."

As I said already in my posting above, my advice was limited to exporting contents of dbf to csv. (x)Harbour's code is quite optimized, keeping in view its capabilities like handling numeric, date, logical fields also, trimming, escaping of strings and also codepage issues.

I did appreciate your discussions on optimizing string operations, reducing memory fragmentation, etc. I clearly stated that I was not discussing that topic. Experts like Mr Carlos and Mr Xmanuel may continue with the topic.

My proposal would be to do it in C, which would avoid dependencies such as those indicated by Carlos and I guarantee that the memory would not fragment at all.
And it could also be used to create a write buffer to a file whose entry could be anything and not just a DBF.

Very good idea. Such a generic function would be useful for many purposes.

Ok, Mr. Rao.
La pongo en otro hilo, para que sea el inicio de una clase que todo el mundo pueda mejorarla.

El hilo se llamará: "TFBuffer, una clase para acelerar la escritura en ficheros"