Timing der Ausführung eines Befehls in PowerShell

Gibt es eine einfache Möglichkeit, die Ausführung eines Befehls in PowerShell zeitlich zu steuern, wie den Befehl 'time' unter Linux?
Ich habe mir das ausgedacht:

$s=Get-Date; .\do_something.ps1 ; $e=Get-Date; ($e - $s).TotalSeconds

Aber ich hätte gerne etwas Einfacheres

time .\do_something.ps1

Jep.

Measure-Command { .\do_something.ps1 }

Beachten Sie, dass ein kleiner Nachteil darin Measure-Commandbesteht, dass Sie keine stdoutAusgabe sehen.

[Update, dank @JasonMArcher] Sie können das Problem beheben , indem Sie die Befehlsausgabe zu einem gewissen Commandlet kochend , dass Schreiben an den Host, zum Beispiel Out-Defaultso wird es:

Measure-Command { .\do_something.ps1 | Out-Default }

Eine andere Möglichkeit, die Ausgabe anzuzeigen, besteht darin, die .NET- StopwatchKlasse wie folgt zu verwenden:

$sw = [Diagnostics.Stopwatch]::StartNew()
.\do_something.ps1
$sw.Stop()
$sw.Elapsed

Sie können auch den letzten Befehl aus dem Verlauf abrufen und EndExecutionTimevon seinem subtrahieren StartExecutionTime.

.\do_something.ps1  
$command = Get-History -Count 1  
$command.EndExecutionTime - $command.StartExecutionTime

Verwenden Measure-Command

Beispiel

Measure-Command { <your command here> | Out-Host }

Mit der Pipe to Out-Hostkönnen Sie die Ausgabe des Befehls anzeigen, der ansonsten von verwendet wird Measure-Command.

Einfache

function time($block) {
    $sw = [Diagnostics.Stopwatch]::StartNew()
    &$block
    $sw.Stop()
    $sw.Elapsed
}

kann dann als verwenden

time { .\some_command }

Möglicherweise möchten Sie die Ausgabe optimieren

Hier ist eine Funktion, die ich geschrieben habe und die ähnlich wie der Unix- timeBefehl funktioniert :

function time {
    Param(
        [Parameter(Mandatory=$true)]
        [string]$command,
        [switch]$quiet = $false
    )
    $start = Get-Date
    try {
        if ( -not $quiet ) {
            iex $command | Write-Host
        } else {
            iex $command > $null
        }
    } finally {
        $(Get-Date) - $start
    }
}

Quelle: https://gist.github.com/bender-the-greatest/741f696d965ed9728dc6287bdd336874

Verwenden der Stoppuhr und Formatieren der verstrichenen Zeit:

Function FormatElapsedTime($ts) 
{
    $elapsedTime = ""

    if ( $ts.Minutes -gt 0 )
    {
        $elapsedTime = [string]::Format( "{0:00} min. {1:00}.{2:00} sec.", $ts.Minutes, $ts.Seconds, $ts.Milliseconds / 10 );
    }
    else
    {
        $elapsedTime = [string]::Format( "{0:00}.{1:00} sec.", $ts.Seconds, $ts.Milliseconds / 10 );
    }

    if ($ts.Hours -eq 0 -and $ts.Minutes -eq 0 -and $ts.Seconds -eq 0)
    {
        $elapsedTime = [string]::Format("{0:00} ms.", $ts.Milliseconds);
    }

    if ($ts.Milliseconds -eq 0)
    {
        $elapsedTime = [string]::Format("{0} ms", $ts.TotalMilliseconds);
    }

    return $elapsedTime
}

Function StepTimeBlock($step, $block) 
{
    Write-Host "`r`n*****"
    Write-Host $step
    Write-Host "`r`n*****"

    $sw = [Diagnostics.Stopwatch]::StartNew()
    &$block
    $sw.Stop()
    $time = $sw.Elapsed

    $formatTime = FormatElapsedTime $time
    Write-Host "`r`n`t=====> $step took $formatTime"
}

Verwendungsbeispiele

StepTimeBlock ("Publish {0} Reports" -f $Script:ArrayReportsList.Count)  { 
    $Script:ArrayReportsList | % { Publish-Report $WebServiceSSRSRDL $_ $CarpetaReports $CarpetaDataSources $Script:datasourceReport };
}

StepTimeBlock ("My Process")  {  .\do_something.ps1 }

Nur ein Wort zum Ziehen (falscher) Schlussfolgerungen aus einem der in den Antworten genannten Leistungsmessbefehle. Es gibt eine Reihe von Fallstricken, die berücksichtigt werden sollten, abgesehen von der bloßen Aufrufzeit einer (benutzerdefinierten) Funktion oder eines Befehls.

Sjoemelsoftware

_{'Sjoemelsoftware' zum niederländischen Wort des Jahres 2015 gewählt
Sjoemelen bedeutet Betrug, und das Wort sjoemelsoftware entstand aufgrund des Volkswagen-Abgasskandals. Die offizielle Definition lautet "Software zur Beeinflussung der Testergebnisse".}

Persönlich denke ich, dass " Sjoemelsoftware " nicht immer absichtlich erstellt wurde, um Testergebnisse zu betrügen, sondern möglicherweise aus einer praktischen Situation resultiert, die den unten gezeigten Testfällen ähnelt.

Beispielsweise wird die Verwendung der aufgelisteten Leistungsmessbefehle, Language Integrated Query (LINQ) ⁽¹⁾ , häufig als der schnellste Weg bezeichnet, um etwas zu erledigen, und dies ist häufig der Fall, aber sicherlich nicht immer! Jeder, der eine Geschwindigkeitssteigerung um den Faktor 40 oder mehr im Vergleich zu nativen PowerShell-Befehlen misst, misst wahrscheinlich falsch oder zieht eine falsche Schlussfolgerung.

Der Punkt ist, dass einige .Net-Klassen (wie LINQ) eine verzögerte Auswertung verwenden (auch als verzögerte Ausführung bezeichnet ⁽²⁾ ). Das heißt, wenn Sie einer Variablen einen Ausdruck zuweisen, scheint dies fast sofort erledigt zu sein, aber tatsächlich wurde noch nichts verarbeitet!

Lassen Sie vermuten , dass Sie dot-Quelle Ihren . .\Dosomething.ps1Befehl , die entweder eine Powershell oder ein anspruchsvolleres Linq Ausdruck hat (für die Einfachheit der Erklärung, habe ich direkt die Ausdrücke direkt in die eingebettet Measure-Command):

$Data = @(1..100000).ForEach{[PSCustomObject]@{Index=$_;Property=(Get-Random)}}

(Measure-Command {
    $PowerShell = $Data.Where{$_.Index -eq 12345}
}).totalmilliseconds
864.5237

(Measure-Command {
    $Linq = [Linq.Enumerable]::Where($Data, [Func[object,bool]] { param($Item); Return $Item.Index -eq 12345})
}).totalmilliseconds
24.5949

Das Ergebnis scheint offensichtlich zu sein. Der spätere Linq- Befehl ist etwa 40-mal schneller als der erste PowerShell- Befehl. Leider ist es nicht so einfach ...

Lassen Sie uns die Ergebnisse anzeigen:

PS C:\> $PowerShell

Index  Property
-----  --------
12345 104123841

PS C:\> $Linq

Index  Property
-----  --------
12345 104123841

Wie erwartet sind die Ergebnisse dieselben, aber wenn Sie genau aufgepasst haben, werden Sie feststellen, dass die Anzeige der $LinqErgebnisse viel länger gedauert hat als die $PowerShellErgebnisse.
Lassen Sie uns dies speziell messen , indem wir nur eine Eigenschaft des resultierenden Objekts abrufen:

PS C:\> (Measure-Command {$PowerShell.Property}).totalmilliseconds
14.8798
PS C:\> (Measure-Command {$Linq.Property}).totalmilliseconds
1360.9435

Das Abrufen einer Eigenschaft des Objekts dauerte etwa einen Faktor 90 länger als das Abrufen $Linqdes $PowerShellObjekts, und das war nur ein einzelnes Objekt!

Beachten Sie auch eine andere Gefahr, dass bestimmte Schritte bei einem erneuten Ausführen möglicherweise viel schneller als zuvor angezeigt werden. Dies liegt daran, dass einige der Ausdrücke zwischengespeichert wurden.

Fazit: Wenn Sie die Leistung zwischen zwei Funktionen vergleichen möchten, müssen Sie diese in Ihrem verwendeten Fall implementieren, mit einer neuen PowerShell-Sitzung beginnen und Ihre Schlussfolgerung auf die tatsächliche Leistung der gesamten Lösung stützen.

_{(1) Für weitere Hintergrundinformationen und Beispiele zu PowerShell und LINQ empfehle ich diese Website: Hochleistungs-PowerShell mit LINQ
(2) Ich denke, es gibt einen geringfügigen Unterschied zwischen den beiden Konzepten, da bei einer verzögerten Bewertung das Ergebnis bei Bedarf berechnet wird Aufgeschobene Ausführung , wenn das Ergebnis berechnet wird, wenn das System inaktiv ist}