Performance issue when using ObservableMemoryLayer

[nabeelio]

Mapsui Version
5.0.2

Mapsui Platform
WPF

Device
Windows 11

Describe the bug

So I just updated the MapsUI library from 5.0.0-beta9 to the latest 5.0.2. And there's a performance issue now with using ObservableMemoryLayer that wasn't in the beta. The rendering gets slower and slower.

Basically I am doing flight tracking and adding the points to an observable line feature. It looks like this:

GeometryFeature? _playerFlownLineFeature;
ObservableCollection<MPoint> _playerFlownVertices;

_playerFlownLineLayer = new ObservableMemoryLayer(GetFeature) {
    Name = "playerPositionLayer",
    Style = FlightPathStyle,
    ObservableCollection = _playerFlownVertices,
};

IFeature? GetFeature(MPoint f)
{
    _playerFlownLineFeature.Geometry = MapUtils.SplitLineForIdl(_playerFlownVertices.ToArray());

    return _playerFlownLineFeature;
}

But now as more features vertices get added, it starts off from around 60+ FPS and starts crawling. Now it's down to 4FPS, the count being 5200. I'm not sure if I'm doing this the right way. But it ends up locking up the entire app.

[pauldendulk]

Thanks for the report.

In general more points obviously means things get slower. Since that was not in beta9 it needs to be investigated.

In the meantime, could you try out the ObservableCollectionLayer which is in the Mapsui.Experimenal packages. It is roughly the same but has a simpler implementation.

[nabeelio]

Cool, I'm trying that out...

• 80 fps, ~1500 count
• 26 fps, ~5000 count, app is a little laggy
• 16 fps, ~6000 count
• 13, ~6100

Lemme remove my SplitLineForIdl method which returns a MultiLineString and try just jamming it into a LineString....

• 34 fps, ~1500
• 24fps, ~4000
• 15 fps, ~5400
• 9 fps ~7400

Trying to see if I can get anything meaningful from a profiler

[nabeelio]

Oh, I'm misreading what count represents. This is when it's down to about 3fps:

[nabeelio]

This is from Rider detecting a UI freeze

[nabeelio]

Expanded that last Render call

[nabeelio]

I'll start downgrading version to see if I can isolate that way

[nabeelio]

rc2 seems to degrade less fast - there's about 400 points in the line and we're at 7fps. Gonna keep going backwards :)

[nabeelio]

Beta 18 - 400 points and it's degraded from about 50fps to 20 or so

[nabeelio]

Sorry for all the comments, just throwing them in as I'm testing

Beta 13 - 400 points in the LineString, started around 80fps , degraded to about 20fps, and just goes down from there.

Maybe this was happening in beta 8 but I will have to get the performance widget working there to know for sure. But I don't think I see which version there was the sharper drop in perf, but I'll walk up the version tree, since now I've settled on setting the FPS between start and 400 points. But I know I have users on Beta 8 with 8/10 hour flights which would correspond to maybe 10k+ points and there's no issues... so maybe I should go down to beta 8 and see if I can get the widget working to get a baseline.

[pauldendulk]

Could you summarize what you have learned so far?

[nabeelio]

Ok, so using a MultiLineString from 0 to 500 points in the line. I'm restarting the app in between tests. I'm also using ObservableMemoryLayer. I think beta14 is when the perf started degrading.

5.0.0-beta13

• 0 points - ~120 fps
• 500 points - ~120 fps

5.0.0-beta14

• I see Fix update of modified ObservableMemoryLayer #2961 with a change to ObservableMemoryLayer, maybe this is relevant

• 0 points - ~120 fps

• 200 points - ~50 fps

• 500 points - ~15 fps

I don't have any explicit calls to FeaturesWereModified()

And this is the GetFeature method (in my original post, I was modifying the Geometry of a static feature)

IFeature? GetFeature(MPoint f)
{
    var points = _playerFlownVertices.ToArray();

    if (points.Length < 2)
        return null;

    return new GeometryFeature {
        Geometry = MapUtils.SplitLineForIdl(points),
    };
}

The other interesting part is that if I start with 500 points in the collection, it will start off at around 120fps, and then degrade once another 500 or so are added.

[pauldendulk]

Thanks for the extensive investigation. I’ve looked at your test results and gone through the code to see what could cause it but I don't see an obvious problem.

ObservableCollection often causes performance problems

I am not a fan of the ObservableCollection because although it is in easy solution for some scenarios it can also cause hard to track performance problems because it is not easy to see how the notifications it triggers affect other parts of the code. It has bitten me quite a few times.

Multiple enumerations

That said, the code changes you point to in beta.14 do not seem to affect the notifications. One thing that could cause a problem is that the _features do a defered execution (go back to the source). This is what happens when you to not do ToArray to ToList on Linq query statement. https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1851

MemoryLayer

The ObservableMemoryLayer is inherited from the MemoryLayer which also had some changes, this could also cause the problem.

ObservableCollectionLayer

The ObservableCollectionLayer is an alternative that basically replaces the ObservableMemoryLayer. It does not inherit from MemoryLayer which makes it easier to understand and maintain. It is currently in the Mapsui.Experimental nuget package. It should not be hard to replacement it for the ObservableMemoryLayer.

Questions

You could help me by answering some questions and doing some follow up tests.

• How do you update changes in your data? Could you paste some code?
• Could you test performance with the ObservableCollectionLayer
• Could you test performance the MemoryLayer (it may have the same problem). You may need to call .Modified() on the geometry if you update it (but perhaps you replace it) and may need to call. Map.Refresh().
• Do you have any code that listens to events emitted by the observable memory layer? what does it do?
• Could you do a .ToList() on the collection that you assign to the Features.

btw, looking at the kind of thing you are doing this is not something where you should use an ObservableCollection, so i think it would be better to change to something else for you, still, I would like to know what causes this behavoir.

[nabeelio]

So this code used to be a memory layer before where I'd just call modified on it/replace it and call Map.Refresh(). That's at least the approach I had in 4.x, and changed it to an observable since that seems more appropriate. I'll look back through my old commits and see if I can find that.

Using ObservableCollectionLayer has the same performance problem in beta13. That's when I realized I was still using it and switched back to the ObservableMemoryLayer.

Let me try to modify one of the examples to see if I can replicate it.

How do you update changes in your data? Could you paste some code?

They come in async from an external source, internally, I use https://github.com/Cysharp/MessagePipe to subscribe async to those data updates. That code looks like this:

private Task SimManagerOnTelemetryEvent(object? sender, TelemetryEventArgs args)
{
    rwl.AcquireReaderLock(TimeSpan.FromMilliseconds(30));
    try {
        if (Pirep == null) {
            Log.Warning("LiveMapViewModel: No PIREP set in telemetry callback");

            return Task.CompletedTask;
        }

        // rate limit the updates
        var timeDiff = DateTime.UtcNow - _lastMapUpdateTime;

        if (timeDiff < TimeSpan.FromMilliseconds(PlayerLayers.UpdatePeriod))
            return Task.CompletedTask;

        _lastMapUpdateTime = DateTime.UtcNow;

        _playerLayers?.Telemetry_OnPositionUpdate(args);
        UpdateMapElements(Pirep);

        if (FollowFlight || !_centeredFirstTime) {
            Map?.Navigator.PanLock = false;
            MoveToCenter(Pirep, args.Data.Location, false);
            Map?.Navigator.PanLock = FollowFlight;
            _centeredFirstTime = true;
        }
    }
    finally {
        rwl.ReleaseReaderLock();
    }

    return Task.CompletedTask;
}

Could you test performance with the ObservableCollectionLayer

Performance degrades regardless of version

Could you test performance the MemoryLayer (it may have the same problem). You may need to call .Modified() on the geometry if you update it (but perhaps you replace it) and may need to call. Map.Refresh().

Yep, I will try this next, gotta dig out some old code

Do you have any code that listens to events emitted by the observable memory layer? what does it do?

Nope

Could you do a .ToList() on the collection that you assign to the Features.

Makes no difference

[nabeelio]

So, I upgraded to 5.0.3, and I changed my implementation (back) to use the WriteableLayer, which clears it and then adds the MultiLineString feature, it's going at 120fps without slowing down