Desempenho da Função Empty()

[Itamar M. Lins Jr.]

Olá!
Fiz um debug, aqui do browse, usando LetoDBf, ficou muito lenta a navegação.
Descobri que é a função empty().
Postei lá no forum de desenvolvedores o problema.
Por exemplo, se uso empty() em um field(campo) do DBF de tamanho 1,2,3 caracteres, ele é rápido.
Mas seu eu uso empty(arquivo pdf) ou uso empty() em um campo FPT anexado um arquivo grande, fica bem lento mesmo.

Editado: É uma rede EXTERNA, não é rede local. E sem fio, das antigas. Abaixo de 65MBs.

[JoséQuintas]

Se isso for problema, tentar alternativas.
Talvez Len( Left( string, 10 ) ) < 1
Se considerar tamanho zero como vazio pra PDF e Memo.
DBF em rede sem fio é problema, não sei com letodbf.

[Itamar M. Lins Jr.]

Olá!
Resolvi lendo um outro campo, que é a extensão do arquivo, ficou bom.
Um campo com tamanho 10, para colocar a extensão, se é pdf/gif/jpeg/doc/xdoc/xls...
Mas fica a dica de degradação, o empty() irá ler todo o arquivo, provavelmente dentro de algum marcador do campo em questão FPT.
Por exemplo <pdf>meu grande pdf</pdf> ao invés dele só ver o inicio e retornar .T., ele ler todo o conteúdo da tag <pdf> sem necessidade.
Não sei como é internamente, não sou programador C, mas que tem esse problema, tem.
No meu código é bem simples é assim: IF Empty(cx->arquivo) // Só isso ai em um campo MEMO FPT. Fica bem lento em rede com baixa velocidade.
Só mudei para IF Empty(cx->sufixo). Ficou normal a velocidade. Isso em 64Mbs. SEM FIO. Não é a 5G nem 4G rsrsrs.
Esse DBF tem mais de 3 mil registros.
Conforme for irei disponibilizar ao forum, algum teste.

[JoséQuintas]

Pelo que entendi lá do fórum internacional, EMPTY() pode ser espaços em branco.
Então num texto de 2GB vai comparar 2GB de letras.
Talvez um loop com saída pra ficar mais rápido, mas aí é com os desenvolvedores.
Fez o teste se realmente o problema é do Empty() ?
Pode ser o tempo pra retornar o campo pela rede, e não exatamente a função.

[Itamar M. Lins Jr.]

Olá!

Pode ser o tempo pra retornar o campo pela rede, e não exatamente a função.

É a função, que lê o FPT ou o ARQUIVO dentro do FPT.(Não sei)
O retorno do Empty() demora, fiz testes. Achei que era o codebock de imagens. Fui mudando até chegar no retorno do empty().
Basta direcionar o empty() para outro FIELD do mesmo DBF que fica rápido.
Tem como eles testarem se é na string em si ou no FPT com vários arquivos dentro.
Assim: IF EMPTy("ABC") e IF EMPTY(&STRING_DO_MEU_FILME_DE_4Gib_MP4)... Pode ver que o tempo do retorno, não será o mesmo.
FPT aceita esses arquivos... DOC,XLS, etc...

Provavelmente o LOAD/UNLOAD disso tudo ai para ver.
Pq precisa dar um LOAD do conteúdo todo, nisso demora.

[JoséQuintas]

Empty() é uma função "local", não da base de dados.
Pra ter o resultado que está querendo, só se ela fosse uma função da base de dados, ou do letodbf.
Mesmo assim, o letodbf vai estar usando 4GB de memória pra acessar o registro/campo.
Talvez um campo adicional com tamanho, gravado ao gravar o campo memo.

[Itamar M. Lins Jr.]

Olá!
Eu conversei lá com o Francesco Perillo.
A função empty() deveria sabe se é uma variável de memória ou um banco de dados.
De toda forma EXISTE os MARCADORES de INICIO e FIM ou de uma variável de memoria ou de base de dados, no caso DBF. Os SLOTs ou CARGO ou CONTAINERs, seja lá como for o nome dado.
Não tem sentido a função ter que ler todo o conteúdo, se logo no inicio ela já sabe que, o que está sendo analisado está cheio ou com espaços.
É simples de entender, um campo com tamanho 5000 só com espaços em banco dentro, neste caso ela empty() pode ficar lenta lendo 1 por 1 pq, neste caso TODOS são barra de espaços.(ok)
Mas se ele começa a ler o mesmo campo e logo no inicio tem um "X" para quê a função continuará lendo até chegar no marcador de final ?
Esse é o problema.

[Itamar M. Lins Jr.]

Olá!

Mesmo assim, o letodbf vai estar usando 4GB de memória pra acessar o registro/campo.

Neste caso o LetoDb acessa o que o OS está acessando 4/8/etc + o SWAP o tanto que o OS consegue acessar.
Está compilado em 64Bits tudo 64Bits. Aqui não uso mais nada em 32Bits, já tem anos isso.
Fiz um teste aqui, ele manda um arquivo no caso ".exe" do cliente para o servidor em menos de 7 segundos. Lógico que irá depender da velocidade da rede. Teste usando meu notebook WIFI. Trabalhando abaixo de 100Mibs. Nem chega a 80Mib.

2025-11-27_16-12-54.png (14.08 KiB) Exibido 142 vezes

[Itamar M. Lins Jr.]

Olá!
Até pq, a função empty() foi modificada a pouco tempo para reconhecer campo com valor NULL e retornar .T. neste caso

[JoséQuintas]

Código: Selecionar todos

DO WHILE ! Eof()
   SKIP
ENDDO

Isso, por si só, já está lendo registros.
E o registro contém.... campos incluindo memo

Sei lá se o letodbf vai fazer diferente.
Se testa Empty() ou não.... o registro já vai ter vindo.
SQL também seria assim, a não ser que peça length() ou algo assim, e só depois peça o "memo" individual.

[Itamar M. Lins Jr.]

Olá!
Sim, mas é o seguinte, não tem nada a ver com LetoDbf esse problema.
Esse problema é do Harbour. Até local usando RDDCDX dá esse problema.
O LetoDbf torna o problema PERCEPTÍVEL nessas redes mais lentas.
Faz um append de um PDF num FPT uns 3 mil e vc vai notar que o empty() em um browse() nesse campo ficará cada vez mais lento.

[Itamar M. Lins Jr.]

Olá!
E mais outra informação.
Outra pessoa falou que no MySql, lá com ele deu o mesmo problema.
Fato é que ninguém quer anexar arquivos em base de dados. O que vejo e jogarem em uma pasta, igual o PHPBB faz.
Eu fiz assim só por comodidade de ficar vários arquivos dentro de 1 só, tipo ZIP.
Então é o seguinte, não existe UPLOAD do DBF todo. A medida que é manipulado/navegado, é mostrado no browse.

Mesma coisa até pior é no MYSQL a pessoa fazer um SELECT de 100 registros cheio de imagens/PDFs... Vai ficar lento da mesma forma.
O que todo mundo faz é subir só o link e deixa o arquivo lá na pasta dele.