Discussion :

[Mkn31]

Bonjour à tous ,
je connais un peu le language vb.net mais j'utilise principalement le language Tcl/tk.
Il y a quelques jours j'ai eu besoin d'extraire des données sur un fichier texte de plusieurs gigaoctets (> 8 gb)
J'ai tenté de le faire en tcl/tk mais sans grande conviction... et ce que je redoutais arriva , un temps de traitement très long.
J'ai donc essayé de faire mon traitement en vb.net.
En parcourant un peu Google la je suis tombé sur ces 2 fonctions : File.ReadLines() et Parallel.ForEach()
Voila à quoi ressemble mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    Sub Main(args As String()) 
 
        Dim po As New ParallelOptions 
        po.MaxDegreeOfParallelism = System.Environment.ProcessorCount 
 
 
        Parallel.ForEach(File.ReadLines(args(0)), po, Sub(line) 
 
                                    If line.Contains(args(1)) Then 
                                        ' traitement données...
                                    End If 
 
                                End Sub)
    End Sub

Et la miracle (ou pas) ... le temps de traitement est drastiquement descendu...
La langue de Shakespeare n'étant pas trop mon fort (je trouve principalement de la doc en Anglais)

Je comprends File.ReadLines(args(0)) : Ouverture du fichier > lecture ligne par ligne > fermeture du fichier
Par contre pour Parallel.ForEach(...) j'ai l'impression que chaque lignes de mon fichier sont traitées dans plusieurs thread et tous cela en parallèle.

Je ne suis pas un expert dans le traitement en parallèle et la plupart du temps je travail en séquentiel
Suis-je dans le vrai ?

Mon but et d'essayer de comprendre ce bout de code pour le réimplanter en tcl/tk.

Merci de votre aide

[Pol63]

t'as à peu près compris je pense

dans un for each à chaque tour tu traites un truc, en exécution pas à pas on voit une ligne jaune qui avance d'un cran à chaque F10
en multi threading c'est comme si un programme pouvait avoir plusieurs lignes jaunes en même temps qui avancent toutes à leur rythme

parallel.foreach permet pour chaque membre d'une collection/tableau (donc comme foreach, et ici pour chaque ligne de ton fichier)
de dire la méthode à exécuter (ici un sub anonyme) et ca se débrouille pour traiter ca sur plusieurs threads (dans ton code ca doit basé sur le nombre de coeurs, donc 8 coeurs = 8 éléments traités en meme temps)
quand un thread a terminé de traiter pour élément il passe au prochain élément non traité
quand tous ont été exécutés alors ca passe à la ligne après le parallel.foreach

après on utilise pas file.ReadAll* sur des gros fichiers, car ca met tout en ram avant de pouvoir commencer à pouvoir faire quelque chose avec
on utilise pas parallel.foreach pour quelque chose qui prend très peu de temps (genre moins d'une milliseconde), ca n'apporte pas grand chose ou rien (au delà oui ca vaut le coup)

le mieux serait donc d'utiliser un filestream, de lire au fur et à mesure => moins d'occupation de la ram et possibilité de commencer à traiter dès le début de la lecture plutot qu'attendre la lecture des x Go
ensuite si ton traitement prend 1ms tu peux le faire pendant la lecture du fichier, si c'est long tu peux paralléliser
concrètement, ca serait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
début boucle
  lire une ligne
  créer une task pour traiter cette ligne ' pas d'attente ici, le taskscheduler s'occupera de lancer la tache dès qu'un thread sera disponible
fin boucle jusqu'à arriver à la fin du fichier

filestream et https://docs.microsoft.com/fr-fr/dot...ew=netcore-3.1 devraient convenir pour lire un fichier

les tasks sont un moyen simple de paralléliser et/où d'asynchroniser

si le traitement est long pour chaque ligne, et que tu veux minimiser la ram prise par l'appli il faut aussi ajouter un moyen de suspendre la boucle quand il y a déjà beaucoup de tache en attente, ce qui ne ralentira pas le temps global d'exécution mais évitera de mettre trop de lignes en ram qui attendront d'être traitées


après si l'amélioration que je propose est compliquée pour toi et/ou que tu t'en fous d'utiliser 8Go de ram tu peux rester sur ton code qui fonctionnera quand même

[Mkn31]

Je comprends mieux

après si l'amélioration que je propose est compliquée pour toi et/ou que tu t'en fous d'utiliser 8Go de ram tu peux rester sur ton code qui fonctionnera quand même

Non non pas du tous aucune raison de m'en foutre c'est toujours bon à prendre
Merci beaucoup @Pol63 d'avoir pris le temps de me répondre
A moi de jouer maintenant

[Pol63]

le "tu t'en fous" était plus un "tu t'en fous" technique que forcément envers toi
parfois on a des grosses machines et un seul programme à faire tourner dessus (c'est rare certes ^^), auquel cas on peut éviter de perdre du temps à optimiser la conso de ram (toujours le compromis avec le temps de dév ...)