Signifficant performance regression when adding large numbers of markers on versions > 2.4.3

[Conbag93]

trafficstars

I have noticed a very large and noticable performance dip when using this library on a map with lots of markers. I haven't extensively tested this - but my MAUI app would render ~1000 markers in a second or two. Now it takes several minutes.

This is occurring even when using Clustering.

Reverting back to version 2.4.3 has fixed the issue for me.

[valentasm1]

2.4.4 works slow for you, but 2.4.3 good? There was change which had to increase performance. Looks like it did opposite. https://github.com/rungwiroon/BlazorGoogleMaps/pull/234

[Conbag93]

2.4.4 works slow for you, but 2.4.3 good? There was change which had to increase performance. Looks like it did opposite. #234

Yes - that's right. In general my use-case requires lots of markers, and performance has never been great in Blazor Server. But it really regressed after 2.4.3.

When using the library in MAUI or WASM, it works well. I suspect that how this has been implemented, the server invokes the JS Interop once-per-marker, which in Blazor Server would incur a round-trip, which all adds up if you're trying to load a map with 100+ markers.

[valentasm1]

Looks like this commit couse issues. Just it doesnt look that i could, but who knows how blazor works :) https://github.com/rungwiroon/BlazorGoogleMaps/pull/234/commits/eba0e2c72266ca582a3883aac362cc0fefc04ddf

Maybe you have some demo to reproduce? I am lazy as cow, so it would help :).

[turner11]

I also had the subjective sense that there was a degregation upgrading from version 2.4.3.
So, tried to benchmark - got the following results for plotting 30k circles:

Release	Commit hash	Time to draw 30K Circles
2.4.3	af257fc48c9415af467439b145468517e7408460	15.7240337
2.4.4	e21303ff6207ecec8af8a3bf8443145ce17bef91	19.0682275
2.5.1	b59d0348b86edead900ff80ee8683872b704b036	Crashes
2.5.6	e0301cb1f32936de2d21cbb276fbb3dc276dc22c	15.3834425
3.0.3	fdd78e2ec6dfde4754561dd0d21e1b4ed81998cd	20.5174454
3.0.8	366c51821ccecb3e185126b92ad575e5449d164e	19.0555363

As @valentasm1 pointed out, the only suspect commit I could find between 2.4.3 and 2.4.4 was eba0e2c72266ca582a3883aac362cc0fefc04ddf, although from just reading its content - I have a hard time beliving its really it + I did not look for changes between 2.5.6 and 3.0.3.
Bottom line - further investigation is requiered,

Note: the timing is for a single try (not average on several attempts), on a new browser tab after restarting the app between attempts (not using hot reload).
For reproducing, you can use the demo page in version 3.1.0 at /dispose-circle-list.

[valentasm1]

@turner11 how about now with .net 8? For me it was 13s. Created 30000 circles in 13,2906363 seconds

[turner11]

@valentasm1 , sorry for the delayed answer. Did not test it in .NET 8. - but look you got some boost in performance for free! In my app I use now sub sampling for arge data sets I'll try to give it a test next week.

[turner11]

@valentasm1 , I got 20.83s I guess your machine is stronger than mine... Conclusion - no noticeable difference.

Disclosure: Since last benchmarking I have update OS to Win 11 + I have a lot of crap running on my machine...

For future reference attaching full table:

Release	Commit hash	Time to draw 30K Circles
2.4.3	af257fc48c9415af467439b145468517e7408460	15.7240337
2.4.4	e21303ff6207ecec8af8a3bf8443145ce17bef91	19.0682275
2.5.1	b59d0348b86edead900ff80ee8683872b704b036	Crashes
2.5.6	e0301cb1f32936de2d21cbb276fbb3dc276dc22c	15.3834425
3.0.3	fdd78e2ec6dfde4754561dd0d21e1b4ed81998cd	20.5174454
3.0.8	366c51821ccecb3e185126b92ad575e5449d164e	19.0555363
4.3.0	88abd6e16097673c0b3779062dc962c1f011c225	20.8311118

[valentasm1]

Thank you for update. I will try to revert back to 2.4.3 this week and maybe maybe i will notice smth :).

[valentasm1]

With 2.3.1 i get quite similar as with current version. Of course need more investigation. Not really could suggest anything.

[valentasm1]

@turner11 how about with 4.7.0 version. Since i am lazy (i told that million times :) ). I run full js optimization with ChatGpt. Now i get ~9-10s, but i havent run test before optimization https://www.nuget.org/packages/BlazorGoogleMaps/4.7.0

[turner11]

@valentasm1 , got 11.90s on tag 4.7.1, Nice job! And ~3 times better using the JS code (did not yet look under the hood to check what you did there...).

For future reference attaching full table again:

Release	Commit hash	Time to draw 30K Circles
2.4.3	af257fc48c9415af467439b145468517e7408460	15.7240337
2.4.4	e21303ff6207ecec8af8a3bf8443145ce17bef91	19.0682275
2.5.1	b59d0348b86edead900ff80ee8683872b704b036	Crashes
2.5.6	e0301cb1f32936de2d21cbb276fbb3dc276dc22c	15.3834425
3.0.3	fdd78e2ec6dfde4754561dd0d21e1b4ed81998cd	20.5174454
3.0.8	366c51821ccecb3e185126b92ad575e5449d164e	19.0555363
4.3.0	88abd6e16097673c0b3779062dc962c1f011c225	20.8311118
4.7.1	4336008	11.9072437

And the methodology:
Timing in table above is for:

• plotting 30k circles:
• a single try (not average on several attempts)
• on a new browser tab after restarting the app between attempts (not using hot reload).

using the page at /dispose-circle-list

[turner11]

Oh - I see what you did in JS.
Its just doing everything in JS - with no need to pass info from server.
I guess its nice for having a baseline for comparison

[valentasm1]

I think we could close it.