This posting on event log queries is worth a read Relevance: Speeding Up Event Log Queries
I think the real key to understanding why your query is crashing the fixlet debugger is to understand how cross-products work in a tuple or whose() block.
When you have a tuple like (set 0, set 1), a cross-product is created where each element of set 0 is paired with each element of set 1
q: (("a";"b";"c"), (1; 2; 3))
A: a, 1
A: a, 2
A: a, 3
A: b, 1
A: b, 2
A: b, 3
A: c, 1
A: c, 2
A: c, 3
A similar thing happens with “whose” clauses. For every item, the ‘whose’ query is executed again. In the case of
(time generated of it, description of it) of records whose (event id of it = 8015 and time generated of it = (maximum of times generated of records whose (event id of it = 8015 ) of system event log)) of system event log
We first find every record. Then for each record we run the whose() filter. The ‘event id of it = 8015’ is simple and fast, but the next step gets more complicated. For every record that was event id 8015, we perform this nested query that again searches the entire event log for every event 8015, and find the maximum times of those events.
On my machine, I have 5 events that match 8015. In this query, it pulls every event, matches against the 5 that are event id 8015, and then performs the nested query - which means I search the entire event log 5 more times to figure out which of the 8015 events has the maximum created time.
To avoid that, what we can do is to move the nested query - the one that finds the most-recent event - to the outside of the whose() clause. By doing this, we can perform that subquery just once, and pass its results into the whose () without have to recalculate the most-recent time.
q: (time generated of it, description of it) of items 0 of (records whose (event id of it = 8015) of system event log, it) whose (time generated of item 0 of it = item 1 of it) of (maximum of times generated of records whose (event id of it = 8015 ) of system event log)
Here, the ‘maximum of times generated’ is only calculated once, and that result is passed in to the tuple to be compared in the whose() block.
On my machine that only had 5 of these events, your original query took T: 5865.039 ms to complete, and my modified version took T: 1518.589 ms.