performance consequences of component per google-maps construct about ember-google-maps

[sandydoo]

I won't deny that there's nothing to be optimized here, but there are things that are out of my scope. Yes, there is overhead with the component system. Yes, we don't need even half of what components offer. Yes, Ember and Google Maps run separate rendering loops with their own schedulers that fight each other. We can't mess with this part of the equation. Perhaps Ember Octane and its simpler components will reduce some of the overhead, perhaps it won't. Maybe custom components are the answer if and when they become available.
Also, I'd like to mention that 1000 markers is not a performance target I'm looking for for this addon. 100-200 is a more realistic target at the moment.

All of that is evaluated at render time despite no marker.infoWindow being shown at render time.

Yes, there is some expensive prep done to avoid rendering lag and weird layout issues when opening an info window. There is totally room for improvement here. You could also try reusing one info window, as suggested by google themselves.

What i've implemented in my own project is a markers-layer that receives all locations for me to render with an inner component for the marker window that's used for a yielded current location.

And this is totally fine. Write a custom component or copy paste what you need. Hopefully, we'll get to a point where you won't need it anymore.

I would advise not dwelling too much over this. We'll see what Ember Octane brings and move on from there. If you do have performance comparisons to post, anything specific you've found, etc, please do.

[acorncom]

@mistahenry given that the 1000 marker scenario probably isn't the focus here, maybe you could develop an ember-maps addon that allows the same sort of declarative api for folks who have performance considerations?

ember-maps-performant-markers or something like that?

[mistahenry]

I would advise not dwelling too much over this.

Taking 12-15 seconds to transition into my route that shows my map on a Google Pixel 3 more or less forced me to dwell on it ;)

Also, I'd like to mention that 1000 markers is not a performance target I'm looking for for this addon. 100-200 is a more realistic target at the moment.

This might be helpful disclaimer in the README. I assumed that I could just enhance this addon to cluster when I had lots of pins, but the current architecture makes that a nonstarter.

I'll close the issue as out of scope of this project

[mistahenry]

@acorncom that's the plan with clustering built in.

[sandydoo]

@mistahenry, in case you're interested, I've published a test app that I've been using to measure the performance of the markers here. Results will vary based on hardware and dev/production build.

ember-google-maps-performance-test

Some results

Perhaps Ember Octane and its simpler components will reduce some of the overhead

• The simpler Glimmer components drastically cut down setup time. There is still substantial overhead.

• Custom components save comparatively little over Glimmer components, since there isn't much else we can cut out from the rendering loop. 😞 Maybe someone knows a way we can create simple functional components? i.e. no rendering, just a method call?

• Helper components are slightly faster that Glimmer components, but are a no-go for some of the more complex components.

• Drawing markers in js is, of course, the best option. However, 1000 markers are still a non-trivial amount.