Use parallel iteration of ordered lists in GetIncompleteCount

[nebel]

Based on your comments on the last PR, I looked into GetIncompleteCount.

My thinking here is that if we can guarantee that config and data are of the same length (already guaranteed), contain the exact same RowIds (I think guaranteed after LuminaTaskUpdater.UpdateConfig and LuminaTaskUpdater.UpdateData?), and are in the exact same order (in practice likely true but perhaps not not guaranteed), we can use parallel iteration of both lists and avoid the LINQ joins.

To make the last part true (sorting guaranteed) I sort the lists after LuminaTaskUpdater's update functions, which is maybe the only location we need to do this based on what I could find.

I think this makes sense, but I left some debug code commented out at the end which you might also want to use to sanity check the old vs new methods. Assuming this approach is feasible, I think the speedups we're likely to see here depend on the user's configuration, but with my relatively simple config I see a speed-up of around 25% (0.550 to 0.400 or so).

[MidoriKami]

and are in the exact same order (in practice likely true but perhaps not not guaranteed)

When a game update occurs missing entries are added to the end of the list, and I don't preclude the possibility that someone copies their configs to a different character that might have stale data.

Your idea of sorting the data only once loaded is a clever one that sufficiently addresses this function of the design.

I have observed a decrease in frametime consumption from 0.0700 to 0.0500ms per frame.

An added benefit of this change is also lower draw time, particularly when viewing the Module Data tab, as each instance of "Incomplete" "Complete" requires GetIncompleteCount.

Nice work, I'll do a little more checking on this one before updating the Dalamud PR.