Check Performance of Event Log Queries

Summary: Ed Wilson, Microsoft Scripting Guy, talks about checking the performance of various event log queries.

Microsoft Scripting Guy, Ed Wilson, is here. One of the great things about Windows PowerShell is that I can use Windows PowerShell to see how it is doing and how to optimize it. Sometimes the difference between one query and another query can be remarkable.

So how can I do performance monitoring for a command? I use the Measure-Command cmdlet. Here is an example of such a command:

Measure-Command -Expression {Get-EventLog -LogName application}

This command uses the Get-EventLog cmdlet to read the entire contents of the application log. The output from the command is shown here:

Image of command output

If I want to compare this with the Get-WinEvent log command, I use a filter hash table that selects all entries from the application log:

Measure-Command -Expression {Get-WinEvent @{logname='application'}}

The output from this command is shown here:

Image of command output

The first command takes less than a second, and the second command takes nearly 20 seconds. Dude, that is significant.

What if I filter on event types? I only want errors. Here is the first command:

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error}

The output is shown here:

Image of command output

It is a little bit faster than the original command, but basically they are the same—less than a second difference.

Here is the same command for the Get-WinEvent cmdlet:

Measure-Command{Get-WinEvent @{logname='application';level=2 }}

The output is shown here:

Image of command output

Interestingly enough, although the “get everything from the application log” command of Get-WinEvent was really slow, it speeds up considerably when also filtering for the entry type. In fact, it came out a little faster than the Get-EventLog command.

What about when filtering with the event ID in addition to the event level? Well, here is the command for Get-EventLog:

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error -InstanceId 490}

The output tells me that basically it does not make much difference for the Get-EventLog cmdlet. 827 milliseconds or 767 milliseconds are essentially the same.

Image of command output

What about adding the event log event ID to the Get-WinEvent cmdlet?

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error -InstanceId 490}

Here is the output:

Image of command output

By adding an event ID to the query, we again speed it up a lot. 61 milliseconds as opposed to 709 milliseconds.

Note  Subsecond comparisons for Measure-Command are not really very accurate, and therefore, they should be taken with a grain of salt. The key is that it again appears to be faster.

If I add a date to the filter with Get-EventLog, it does not appear to make much difference:

Measure-Command -Expression {Get-EventLog -LogName application -EntryType error -InstanceId 490 -After 10/1/2015}

Adding the start time to the Get-WinEvent query also does not make much difference:

Measure-Command{Get-WinEvent @{logname='application';level=2;id=490;Starttime='10/1/2015'}}

The two commands and their associated output are shown here:

Image of command output

That is all there is to using Measure-Command to check the performance of different queries. Join me tomorrow when I will begin a video recap of event log querying. 

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (1)

  1. MockMyBeret says:

    I haven’t tried these out, but could there be some caching that we could attribute the highly disparate times of get-winevent to?

Skip to main content