WD Chargement d'un gros fichier texte dans hyperfile

Kill3rbko · Fev 25, 2023

Bonsoir à tous!

Je sèche depuis un moment sur le chargement d'un fichier texte de 1 Go dans un fichier HF.

Pour cela j'ai utilisé 2 méthodes :

- Himportetexte
- fouvre

Himportetexte est plus rapide que fouvre mais je le trouve encore très lent (environ 20 min)

Je me demandais si l'on pouvait utiliser les tâches parallèles sur la fonction flitligne de manière à faire plusieurs hajoute en parralèle.

Merci pour les conseils!

Dandypunk · Fev 26, 2023

Bonjour,
C'est une solution qui peut être envisagée, en prenant soin de choisir la bonne option de contexte HFSQL.
Sera-t-elle plus rapide que HImporteTexte, c'est à voir. Le problème de rapidité du séquentiel provient des (très nombreux dans ton cas) accès disque lors de la lecture et de l'écriture sans oublier l'éventuel accès RSO.
Une autre solution à envisager est de travailler sur un tableau de chaînes obtenu via fChargeTexte+TexteVersTableau.
Dans les 2 cas, il y aura une troisième variable à prendre en compte, la mémoire disponible (1 Go sur le disque=1Go en mémoire)

Kill3rbko · Fev 26, 2023

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

Bonjour,
C'est une solution qui peut être envisagée, en prenant soin de choisir la bonne option de contexte HFSQL.
Sera-t-elle plus rapide que HImporteTexte, c'est à voir. Le problème de rapidité du séquentiel provient des (très nombreux dans ton cas) accès disque lors de la lecture et de l'écriture sans oublier l'éventuel accès RSO.
Une autre solution à envisager est de travailler sur un tableau de chaînes obtenu via fChargeTexte+TexteVersTableau.
Dans les 2 cas, il y aura une troisième variable à prendre en compte, la mémoire disponible (1 Go sur le disque=1Go en mémoire)
Cliquez pour agrandir...

Dandypunk · Fev 26, 2023

Il me semble avoir déjà été confronté à ce genre de problème.
De mémoire, j'avais contourné le problème en utilisant fChargeBuffer qui permet de "découper" le fichier via les paramètres début/fin.
Attention toutefois aux derniers octets, (ceux situés après le dernier séparateur de ligne) qu'il va falloir supprimer du buffer et récupérer pour la prochaine lecture

Gemini1961 · Fev 26, 2023

Bonjour
Effectivement fractionner le fichier me semble une bonne solution, c'est d'ailleurs la méthode que j'ai adopté lorsque j'ai été confronté à un problème identique;
Attention aussi au caractère blanc insécable, lui aussi m'a posé quelques soucis ;-)
Bien cordialement

Kill3rbko · Fev 26, 2023

Excellente idée, je crois commencer à voir le bout du tunnel avec la fonction fdécoupe.

Par contre fdécoupe "découpe" le fichier en fonction de la taille et du coup mes différent fichiers se retrouvent avec la ligne de début et de fin tronquée d'un fichier à l'autre.

Gemini1961 · Fev 26, 2023

Chaque ligne du fichier représente t'elle un enregistrement ou est-ce un fichier binaire ?

Gemini1961 · Fev 26, 2023

Un solution consiste à garder l'enregistrement tronqué ( de ne pas le traiter) et l'ajouter en début de la découpe suivante ( afin de le traiter quand il est complet )
;-)

Kill3rbko · Fev 26, 2023

Chaque ligne represente juste un email et mot de passe du genre :

Code (Text):

annyvdeynde@hotmail.com:teigertje
lesly__30@hotmail.com:doguito
zulicharun@hotmail.com:19921102h
yakuberol02@hotmail.com:yakups02
mertkeles28@hotmail.com:123456
bir_fizikci@hotmail.com:6546031
haley_nicole_c@hotmail.com:destiney7
gfdgsfds@hotmail.com:1234
isimsizbumsnxx@hotmail.com:123456123456
golden75boy@hotmail.com:1321

et oui chaque ligne est un enregistrement dans mon fichier HF

Mon souci est que je n'arrive pas à lancer plusieurs lectures des differents fichiers dans les threads.

Dandypunk · Fev 26, 2023

Au lieu de fdécoupe, j'envisageais plutôt l'utilisation de fChargeBuffer qui est un peu plus souple
un truc du style :

Code (Windev):

saCheminFichier est chaîne
bufTravail est Buffer
nOffset est entier //Début de la lecture
nTaillePartielles est entier //Taille des données entre le dernier CRLF et la fin de la lecture
nTailleBuffer est entier //Taille à lire
tabDonnées est tableau de chaînes //Données à exploiter
tabTemp est tableau de chaînes //Données lues dans la boucle
nNoPassage est entier

nTailleBuffer = 25000
bufTravail =
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(saCheminFichier,0,nTailleBuffer)
TANTQUE
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(bufTravail,CRLF,0,DepuisFin)<>0
nNoPassage++
//On récupère les données exploitables
bufTravail=bufTravail[[ À
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(bufTravail,CRLF,0,DepuisFin)]]
nTaillePartielles=nTailleBuffer-
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(bufTravail)-1

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(bufTravail,tabTemp,CRLF)

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(tabDonnées,tabTemp)

//On calcule la position des données "partielles"
nOffset=nNoPassage*nTailleBuffer-nTaillePartielles
bufTravail=
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(saCheminFichier,nOffset,nTailleBuffer)
FIN

Kill3rbko · Fev 26, 2023

Ouh là Dandy!!!!

merci énormément pour le code.
Je regarde tout de suite

Bon apparemment j'ai toujours ce souci mémoire dès qu'on fait le tableauajoute du tableau temp même en diminuant 10x la taille du buffer.

Code (Text):

Error at line 80 of Clic sur BTN_Select6 process.
ArrayAdd function called.
Insufficient memory.
If you handle large amounts of data, consider switching the application to 64 bits.

Gemini1961 · Fev 26, 2023

je ne pense pas que ce soit la taille du buffer qui pose problème mais bien la taille du tableau.
A quel indice de tableau (nNoPassage) se plante le tableau ?
Sans quoi peut-être envisager de travailler avec plusieurs tableaux,
le changement de tableau se ferait en fonction de l'indice ( nNoPassage)

Dandypunk · Fev 26, 2023

Compiles-tu en 32 ou 64 bits ? En 32 bits, on a le plafond des 2Go.

Kill3rbko · Fev 26, 2023

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

Compiles-tu en 32 ou 64 bits ? En 32 bits, on a le plafond des 2Go.
Cliquez pour agrandir...

Dandypunk · Fev 26, 2023

En ce qui concerne les chaînes, TableauCherche recherche la totalité d'une chaîne. On peut toutefois se bricoler une fonction TableauContient

Code (Windev):

FONCTION TableauContient(LOCAL tabNomTableau est tableau de chaînes,LOCAL saValeurCherchée est chaîne,LOCAL nIndDébutRecherche est entier=1):entier
nNoLigne est un entier

POUR nNoLigne=nIndDébutRecherche _À_ tabNomTableau..
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

SI
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(tabNomTableau[nNoLigne],saValeurCherchée) ALORS
RENVOYER nNoLigne
FIN
FIN
RENVOYER -1

Utilisation

Code (Windev):

nRes=TableauContient(tabTravail,"D")
TANTQUE nRes<>-1

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(nRes)
nRes=TableauContient(tabTravail,"D",nRes+1)
FIN

Kill3rbko · Fev 26, 2023

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

En ce qui concerne les chaînes, TableauCherche recherche la totalité d'une chaîne. On peut toutefois se bricoler une fonction TableauContient

[/code]
Cliquez pour agrandir...

Gemini1961 · Fev 27, 2023

Une petite variante sur la même base ;-)

FONCTION Tableau_Contient( LOCAL p_oTableauDeChaines est tableau de chaînes ...
, LOCAL p_sValeurRecherchee est chaîne ...
, LOCAL p_IndiceDepartRech est entier = 1) <sans PAS À PAS> : entier
LOCAL
iTableauOccurr est un entier = p_oTableauDeChaines..Occurrence
iTableauIndice est un entier = -1

SI iTableauOccurr <= p_IndiceDepartRech ALORS
POUR iTableauIndice = p_IndiceDepartRech _À_ iTableauOccurr
SI Contient(p_oTableauDeChaines[iTableauIndice], p_sValeurRecherchee) ALORS
iTableauIndice = iTableauIndice
SORTIR
FIN
FIN
FIN

RENVOYER (iTableauIndice)

Bien cordialement

FEKWX

WD Chargement d'un gros fichier texte dans hyperfile

Kill3rbko Member

Dandypunk Well-Known Member

Kill3rbko Member

Fichiers attachés:

2023-02-26_11h47_01.png

Dandypunk Well-Known Member

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Kill3rbko Member

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Kill3rbko Member

Dandypunk Well-Known Member

Kill3rbko Member

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Dandypunk Well-Known Member

Kill3rbko Member

Dandypunk Well-Known Member

Kill3rbko Member

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Partager cette page

Recherches utiles

WD Chargement d'un gros fichier texte dans hyperfile

Kill3rbko Member

Dandypunk Well-Known Member

Kill3rbko Member

Fichiers attachés:

2023-02-26_11h47_01.png

Dandypunk Well-Known Member

Gemini1961 Well-Known Member MEMBRE WX DUMP TEAM

Kill3rbko Member

Gemini1961 Well-Known Member MEMBRE WX DUMP TEAM

Gemini1961 Well-Known Member MEMBRE WX DUMP TEAM

Kill3rbko Member

Dandypunk Well-Known Member

Kill3rbko Member

Gemini1961 Well-Known Member MEMBRE WX DUMP TEAM

Dandypunk Well-Known Member

Kill3rbko Member

Dandypunk Well-Known Member

Kill3rbko Member

Gemini1961 Well-Known Member MEMBRE WX DUMP TEAM

Partager cette page

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM

Gemini1961 Well-Known Member
MEMBRE WX DUMP TEAM