Zstandard - Algoritmo de compressão

[André Corrêa]

Boa tarde,

Utilizamos atualmente as funções de compactação/descompactação do próprio Harbour para salvar diversos arquivos, e nunca tivemos problema.
Porém, em alguns clientes com muitos arquivos (mais de 400 mil), principalmente XMLs de documentos fiscais, o processo tem se tornado muito lento.
Pesquisando algoritmos ou bibliotecas mais modernas e eficientes, encontramos o Zstd ( Zstandard ), criado pelo Facebook e utilizado por diversas
grandes empresas que trabalham com quantidades enormes de dados. Analisando os benchmarks e casos de uso, parece ser bastante eficiente, ficando
entre os mais rápidos e mantendo boas taxas de compressão. No site https://facebook.github.io/zstd/#other-languages existem exemplos e
wrapers para diversas linguagens, incluindo C, Delphi, VB6, porém, estou com dificuldade em aproveitá-los para que possa utilizar no Harbour.

Tentei o seguinte:
Incluí os cabeçalhos zstd.h e stddef.h, carreguei a dll com HB_LibLoad e chequei o valtype, que retornou "P", ou seja, ela foi carregada corretamente.
Tentei chamar a função ZSTD_Compress com HB_Dyncall, conforme abaixo, mas acusa erro de GPF:

Código: Selecionar todos

hDll := HB_LibLoad(Application:cDirectory+"libzstd.dll")
hb_dynCall( { "ZSTD_compress", hDll, HB_DYN_CALLCONV_STDCALL }, Application:cDirectory+"teste.txt" )

Acredito que falte passar algum parâmetro para a função, mas não consegui identificar como fazer.
Se alguém puder ajudar a traduzir um dos exemplos para o Harbour, ou ao menos indicar o que falta ou o que está errado, ficarei muito grato.

Obrigado,

[JoséQuintas]

Talvez somente no Harbour 3.4 que é mais padronizado, mas mesmo assim, precisa ver exatamente o tipo de cada variável.
Há diversos tipos numéricos, não são todos iguais, e passar errado dá GPF.
Talvez o fonte pra VB6 seja o mais indicado.

Mas 400.000 documentos... difícil alguma coisa rápida.

[JoséQuintas]

Código: Selecionar todos

Private Declare Function ZSTD_compress Lib "libzstd" Alias "_ZSTD_compress@20" (ByVal ptrToDstBuffer As Long, ByVal dstBufferCapacityInBytes As Long, ByVal constPtrToSrcBuffer As Long, ByVal srcSizeInBytes As Long, ByVal cCompressionLevel As Long) As Long

Private Declare Function ZSTD_compress Lib "libzstd" Alias "_ZSTD_compress@20"

Isso indica que PARA O VB a função é ZSTD_compress
Fica dentro da DLL libzstd
O nome interno, dentro da DLL, é "_ZSTD_compress@20"

ByVal indica valor, caso fosse ByRef seria por referência (@ no Harbour)

Tudo está As Long, o que indica número inteiro longo, número inteiro no Harbour

Só que, se não me engano, ptr é ponteiro... e aí entra criar uma área de memória pra isso, com um tamanho mínimo obrigatório, e converter o ponteiro pra numérico.... complicou.... até porque falta informação sobre essa área de memória.

Sei lá... vai ser muita leitura e muito trabalho.
Se fosse pra mim, preferia deixar o original do Harbour, e nem perder tempo com isso.
Talvez.... mas talvez... tentar acelerar o do Harbour, reduzindo acesso a disco.
Mas é muito trabalho, pra talvez acelerar, ou talvez só perder tempo.

[JoséQuintas]

Comece com um simples:

Código: Selecionar todos

Private Declare Function ZSTD_versionNumber Lib "libzstd" Alias "_ZSTD_versionNumber@0" () As Long

Vai retornar a versão.

AH é... 400.000 XMLs....
Será que 32 bits é suficiente? ou 64 bits?

[JoséQuintas]

Pergunta meio idiota....

Por acaso pegou algum utilitário pronto, indicado lá, pra testar se vai valer a pena?

[wmanesco]

Será que não vale a pena pegar em C, e utilizar a API em C do harbour para criar a ponte? Acho que vale mais a pena...

Normalmente utilizo assim para utilizar ".so" e algumas dlls com tipo mais complexo

[JoséQuintas]

O melhor mesmo é pegar um programa pronto e fazer o teste comparativo.

É esse resultado que vai dizer se vale a pena ou não qualquer outra coisa.

[rochinha]

Amiguinhos,

wmanesco
Não sei se ajuda, mas dê uma olhada nestes tópico compressão/des-compressão de string e texto de/para Base64.

[wmanesco]

Ola.

Eu acho que a questão seria usar o método Zstandard (que pelo que entendi trata-se de algo novo e que possui escritores em C). Pensando nisso, caso ele decida por utilizar, na minha visão a forma mais facil é pegar o fonte que foi feito em C, utilizar a hbapi e criar uma ponte para utilizar no harbour. Não entrei no mérito de ser ou não melhor que algo...

Até mais

[asimoes]

Olá,

Procure por http://www.nirsoft.net/utils/dll_export_viewer.html

DLL Export Viewer

Com esse utilitário vai conseguir ler os métodos dessa dll

Esse é pago: http://www.pe-explorer.com/peexplorer-t ... n-view.htm

[André Corrêa]

Bom dia,

Pessoal, obrigado pelas respostas.

JoséQuintas, vou gerar os testes comparativos e postar os resultados aqui.

wmanesco, também acho que seria o ideal, mas ainda não tenho o conhecimento
necessário para criar os wrapers em C.

asimoes, muitíssimo obrigado pela indicação do utilitário, era exatamente o que
estava procurando. Vou testá-lo e tentar chegar a algum resultado.

Rochinha, já utilizamos a compressão das strings para base 64, o que demora, é
a compactação dos arquivos em um arquivo .ZIP.

Obrigado,

[André Corrêa]

JoséQuintas,

Fiz testes utilizando os utilitários já compilados dos compactadores ZStandard e LZ4 e aparentemente, não vale o esforço.
Acredito que os tempos e tamanhos do arquivo final ficaram muito próximos, devido à quantidade e formato dos arquivos (texto).
Testei compactando cerca de 300 mil arquivos, sendo em sua maioria, XMLs de documentos fiscais. Utilizei as taxas médias
de compactação de cada biblioteca.
O tempo varia um pouco em decorrência do uso da CPU por outros aplicativos ou processos.

Seguem os resultados:

O HB_ZipFile() levou entre 15 e 20 minutos.
O ZStandard levou entre 15 e 25 minutos.
O LZ4 levou entre 14 e 19 minutos.

Percebi que o que gera o maior gargalo, como você já havia adiantado, é mesmo o uso do disco.
Como são muitos arquivos, haveria algum meio de diminuir o acesso ao disco?

Atenciosamente,