Czas wykonywania polecenia w PowerShell

Czy istnieje prosty sposób na czas wykonania polecenia w programie PowerShell, taki jak polecenie „time” w systemie Linux?
Wymyśliłem to:

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

Ale chciałbym coś prostszego

time .\do_something.ps1

Tak.

Measure-Command { .\do_something.ps1 }

Zauważ, że jednym niewielkim minusem Measure-Commandjest to, że nie widzisz żadnych stdoutwyników.

[Aktualizacja, dzięki @JasonMArcher] Możesz to naprawić, przesyłając dane wyjściowe polecenia do jakiegoś polecenia, które zapisuje na hoście, np Out-Default. Staje się:

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

Innym sposobem na sprawdzenie wyniku byłoby użycie Stopwatchklasy .NET w następujący sposób:

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

Możesz także pobrać ostatnie polecenie z historii i odjąć je EndExecutionTimeod niego StartExecutionTime.

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

Posługiwać się Measure-Command

Przykład

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

Potok do Out-Hostpozwala zobaczyć dane wyjściowe polecenia, które w przeciwnym razie jest zużywane Measure-Command.

Simples

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

następnie można użyć jako

time { .\some_command }

Możesz dostosować dane wyjściowe

Oto funkcja, którą napisałem, która działa podobnie do timepolecenia Unix :

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
    }
}

Źródło: https://gist.github.com/bender-the-greatest/741f696d965ed9728dc6287bdd336874

Korzystanie ze stopera i formatowanie upływającego czasu:

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"
}

Próbki użycia

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

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

Tylko słowo na temat wyciągania (niepoprawnych) wniosków z dowolnych poleceń pomiaru wydajności, o których mowa w odpowiedziach. Istnieje szereg pułapek, które należy wziąć pod uwagę oprócz patrzenia na sam czas wywołania (niestandardowej) funkcji lub polecenia.

Sjoemelsoftware

_{„Sjoemelsoftware” przegłosowało holenderskie słowo roku 2015
Sjoemelen oznacza oszustwo, a słowo sjoemelsoftware powstało z powodu skandalu emisyjnego Volkswagena. Oficjalna definicja to „oprogramowanie używane do wpływania na wyniki testów”.}

Osobiście uważam, że „ Sjoemelsoftware ” nie zawsze jest celowo tworzone w celu oszukiwania wyników testów, ale może wynikać z przystosowania się do praktycznej sytuacji podobnej do przypadków testowych, jak pokazano poniżej.

Jako przykład, za pomocą poleceń wymienionych pomiarów wydajności, LINQ (LINQ) ⁽¹⁾ , jest często kwalifikowane jako na czczo sposób coś zrobić i to często jest, ale na pewno nie zawsze! Każdy, kto mierzy wzrost prędkości o współczynnik 40 lub więcej w porównaniu z natywnymi poleceniami PowerShell, prawdopodobnie nieprawidłowo mierzy lub wyciąga błędne wnioski.

Chodzi o to, że niektóre klasy .Net (jak LINQ) używają leniwej oceny (zwanej także odroczonym wykonaniem ⁽²⁾ ). Oznacza to, że przypisanie wyrażenia do zmiennej wydaje się prawie natychmiastowe, ale w rzeczywistości nic jeszcze nie przetworzyło!

Załóżmy, że wklejasz swoje . .\Dosomething.ps1polecenie, które ma albo PowerShell albo bardziej wyrafinowane wyrażenie Linq (dla ułatwienia wyjaśnienia, bezpośrednio osadziłem wyrażenia bezpośrednio w 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

Wynik wydaje się oczywisty, późniejsze polecenie Linq jest około 40 razy szybsze niż pierwsze polecenie PowerShell . Niestety nie jest to takie proste ...

Wyświetlmy wyniki:

PS C:\> $PowerShell

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

PS C:\> $Linq

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

Zgodnie z oczekiwaniami wyniki są takie same, ale jeśli zwrócisz szczególną uwagę, zauważysz, że wyświetlenie $Linqwyników zajęło dużo więcej czasu niż $PowerShellwyników.
Zmierzmy to konkretnie , po prostu pobierając właściwość wynikowego obiektu:

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

Pobranie właściwości obiektu niż obiektu zajęło około 90 razy dłużej i był to tylko jeden obiekt!$Linq$PowerShell

Zauważ też inną pułapkę, że jeśli zrobisz to ponownie, niektóre kroki mogą pojawić się znacznie szybciej niż wcześniej, ponieważ niektóre wyrażenia zostały buforowane.

Podsumowując, jeśli chcesz porównać wydajność między dwiema funkcjami, musisz zaimplementować je w używanym przypadku, rozpocząć od nowej sesji PowerShell i oprzeć swój wniosek na rzeczywistej wydajności kompletnego rozwiązania.

_{(1) Aby uzyskać więcej informacji na temat PowerShell i LINQ, i przykładów, polecam tihis site: High Performance PowerShell with LINQ
(2) Myślę, że istnieje niewielka różnica między tymi dwiema koncepcjami, ponieważ w przypadku leniwej oceny wynik jest obliczany, gdy jest potrzebny, w odniesieniu do odroczone wykonanie , gdy wynik jest obliczany, gdy system jest bezczynny}