Ordenar (SORT) uma Hash Table

[asimoes]

Kkk, tô ficando velho, muito velho pra isso,
A novidade é atribuir nil para hrecord
No meu posto não tem

[fladimir]

Testei com uma base de 1.118.902 registros tendo cada registro 69 colunas/campos

Baseando no codigo do Quintas, testei com While e DBEVAL... ai depois de um tempo rodando cai fora da rotina... ai abrindo o hb_out.log da impressão q houve uma falha de memoria, mas não poderia não é?

Segue hb_out.log do DBEVAL

Código: Selecionar todos

Terminated at: 2018-10-24 13:03:52
Unrecoverable error 9009: hb_xrealloc can't reallocate memory
Called from HB_HSET(0)
Called from (b)IMG9(13) in _Testes.prg
Called from DBEVAL(0)
Called from IMG9(17) in _Testes.prg
Called from MAIN(238) in menu.prg
------------------------------------------------------------------------

Segue hb_out.log do WHILE

Código: Selecionar todos

Terminated at: 2018-10-24 13:08:23
Unrecoverable error 9009: hb_xrealloc can't reallocate memory
Called from HB_HSET(0)
Called from IMG9(14) in _Testes.prg
Called from MAIN(238) in menu.prg
------------------------------------------------------------------------

Alguém teria alguma sugestão do q poderia ser?

[JoséQuintas]

o que tem nessas linhas? 13, 14, 17 de img9 ?

[JoséQuintas]

E qual o tamanho do registro?
Se cada campo tiver 1 byte, que não é, já dá uns 70MB
Se tiver campo memo então... vixe... 32 bits limita a 4GB.

[JoséQuintas]

1 milhão de registros. 1MB.
Cada registro com 4000 bytes.. 4GB.... impossível em 32 bits.
Se fiz a conta direito... rs

[JoséQuintas]

Conta simples:
Quanto é o tamanho do DBF + FPT, se é que isso é dbf...
Ou o tamanho no MySQL, se for MySql...

[fladimir]

Tamanho da tabela 925 MB

[JoséQuintas]

Não bate com a linha do erro.
No dbeval mostra o erro na linha 17, que chama a 13.
A 17 é dbskip()

Dependendo da rotina, se passa a variável por parâmetro, vai ser quase 1GB pra cada chamada, lembre-se disso.

a := 1GB
Funcao( a )

Isso são 2GB.

[JoséQuintas]

O inverso também

a := ConverteHash()

Vai precisar gravar 1GB em a, antes de destruir o 1GB da subrotina.

[fladimir]

o erro é no hb_hSet

depois de cerca de 275mil registros ocorre o erro.

Eu fiz um teste no FOR ... FCount() q varre as colunas do registro, mudei pra fazer até a coluna 10, passou, ou seja, esta estourando mesmo.
Vou ver até q coluna preciso e deixar assim, mas isso é ruim pq uma hora vai dar problema conforme crescer mais a tabela.

[JoséQuintas]

Use arquivos temporários.
Nunca vai ter problema de memória.
É assim que o Windows funciona.

Tem essa também.... vai depender de que programas o cliente carrega ao mesmo tempo, pra saber o limite. Pode funcionar aí e no cliente não.

[fladimir]

Quintas, se não for pedir muito, da uma ideia do exemplo do teu código (imagem) como ficaria com arquivo temporário.

[JoséQuintas]

Mais ou menos isto:

Código: Selecionar todos

cTmpFile := MyTempFile()
SELECT 0
dbCreate( cTmpFile, arquivo->( dbStruct() ) )
USE (cTmpFile) ALIAS temp
DO WHILE ! arquivo->( Eof() )
   RecAppend()
   FOR nCont = 1 TO FCount()
      FieldPut( nCont, arquivo->( FieldGet( nCont ) )  )
   NEXT
   arquivo->( dbSkip() )
ENDDO

[JoséQuintas]

Talvez seja bom um Inkey() aí no meio, ou equivalente em tela gráfica.
É para não roubar todo tempo do Windows, e no caso de GUI pra não congelar a tela até o término.

[fladimir]

Deu certo mas fica muito lento.

Resolvi da seguinte forma, crio um indice temporario reduzindo o range de registros, exemplo periodo tal... ai em cima disso crio uma hashtable
Ai fica rapido e resolve
Agora criar a hash ou arquivo temporario a partir da tabela original sem filtro nenhum antes no cenario q apresentei aki demora demais.