Sorte de très gros fichier texte en PowerShell

Get-Content est terriblement inefficace pour la lecture des fichiers volumineux. Sort-Object n'est pas très rapide, trop.

Nous allons définir une ligne de base:

$sw = [System.Diagnostics.Stopwatch]::StartNew();
$c = Get-Content .\log3.txt -Encoding Ascii
$sw.Stop();
Write-Output ("Reading took {0}" -f $sw.Elapsed);

$sw = [System.Diagnostics.Stopwatch]::StartNew();
$s = $c | Sort-Object;
$sw.Stop();
Write-Output ("Sorting took {0}" -f $sw.Elapsed);

$sw = [System.Diagnostics.Stopwatch]::StartNew();
$u = $s | Get-Unique
$sw.Stop();
Write-Output ("uniq took {0}" -f $sw.Elapsed);

$sw = [System.Diagnostics.Stopwatch]::StartNew();
$u | Out-File 'result.txt' -Encoding ascii
$sw.Stop();
Write-Output ("saving took {0}" -f $sw.Elapsed);

Avec 40 MO fichier de 1,6 million de lignes (100k unique des lignes répété 16 fois) ce script génère la sortie suivante sur ma machine:

Reading took 00:02:16.5768663
Sorting took 00:02:04.0416976
uniq took 00:01:41.4630661
saving took 00:00:37.1630663

Totalement anodin: plus de 6 minutes pour trier minuscule fichier. Chaque étape peut être beaucoup améliorée. Nous allons utiliser StreamReader de lire le fichier ligne par ligne dans HashSet qui permettra de supprimer les doublons, puis copier les données à List et de les trier, puis utilisez StreamWriter pour le vidage des résultats.

$hs = new-object System.Collections.Generic.HashSet[string]
$sw = [System.Diagnostics.Stopwatch]::StartNew();
$reader = [System.IO.File]::OpenText("D:\log3.txt")
try {
    while (($line = $reader.ReadLine()) -ne $null)
    {
        $t = $hs.Add($line)
    }
}
finally {
    $reader.Close()
}
$sw.Stop();
Write-Output ("read-uniq took {0}" -f $sw.Elapsed);

$sw = [System.Diagnostics.Stopwatch]::StartNew();
$ls = new-object system.collections.generic.List[string] $hs;
$ls.Sort();
$sw.Stop();
Write-Output ("sorting took {0}" -f $sw.Elapsed);

$sw = [System.Diagnostics.Stopwatch]::StartNew();
try
{
    $f = New-Object System.IO.StreamWriter "d:\result2.txt";
    foreach ($s in $ls)
    {
        $f.WriteLine($s);
    }
}
finally
{
    $f.Close();
}
$sw.Stop();
Write-Output ("saving took {0}" -f $sw.Elapsed);

ce script produit:

read-uniq took 00:00:32.2225181
sorting took 00:00:00.2378838
saving took 00:00:01.0724802

Sur le même fichier en entrée, il s'exécute plus de 10 fois plus rapide. Je suis toujours surpris si il faut 30 secondes pour lire le fichier à partir du disque.

OriginalL'auteur n0rd

(Édité pour être plus clair basé sur n0rd commentaires)

C'est peut-être un problème de mémoire. Puisque vous êtes en train de charger tout le fichier en mémoire afin de les trier (et l'ajout de la surcharge de la pipe en Sorte que l'Objet-et le tuyau dans Get-Unique), il est possible que vous frappez les limites de la mémoire de la machine, et l'obliger à la page sur le disque, ce qui va ralentir les choses beaucoup. Une chose que vous pourriez envisager est diviser les journaux avant de les trier, puis l'épissage de l'ensemble.

Ce ne sera probablement pas correspondre à votre format exactement, mais si j'ai un gros fichier journal pour, disons, 8/16/2012 qui s'étend sur plusieurs heures, je peux la découper en un fichier différent pour chaque heure en utilisant quelque chose comme ceci:

for($i=0; $i -le 23; $i++){ Get-Content .\u_ex120816.log | ? { $_ -match "^2012-08-16 $i`:" } | Set-Content -Path "$i.log" }

C'est la création d'une expression régulière pour chaque heure de la journée et de dumping tous les entrées de journal dans un plus petit fichier journal nommé par heure (par exemple 16.journal, 17.le journal).

Alors, je peux utiliser votre processus de tri et d'obtenir les entrées uniques sur une beaucoup plus petite sous-ensembles, qui doit courir beaucoup plus vite:

 for($i=0; $i -le 23; $i++){ Get-Content "$i.log" | sort | get-unique > "$isorted.txt" }

Et puis vous pouvez épissure ensemble.

En fonction de la fréquence des journaux, il pourrait faire plus de sens de les diviser par jour, ou minutes; la chose principale est de les obtenir dans de plus petits morceaux gérables pour le tri.

Encore une fois, cela n'a de sens que si vous frappez les limites de la mémoire de la machine (ou si Tri-Objet est d'utiliser un algorithme inefficace).

OriginalL'auteur E.Z. Hart