This has gotten slower with the updates when there are lots of options, like selecting a country

[robclancy]

No description provided.

[amk221]

Hmm, I do have a vague test to check it's not regressed in speed.

I wonder, for your use case, is using native <option>'s an option?

[amk221]

I have been frustrated in the past with the slowness of the component. Considering all it is doing is comparing 1 value with another, I would expect it to be lightning fast. So I can only attribute the slowness to the quantity of components (i.e. Ember's component construction time). But it's definitely worth investigating more

[amk221]

I've also noticed a larger than expected difference in development speeds vs production speeds

[amk221]

I'm going to set up a dedicated test app

[amk221]

...ok, I don't think this has got any slower recently.

But it does seem to be a downside of the architecture - In that each option is a component.

[robclancy]

Yeah I looked over things a fair bit and didn't notice anything that should cause issues. But I updated from the 10 beta and there was a very noticeable difference. For now I changed from creating the options when you open it to just having them created with the select and then hide it. The reason I switched to this add-on it because you put the power in the devs hands and speed. I did some profiling and it seemed there was a lot of tracking things. But not sure. Hopefully I can find some time to setup something to reproduce and test/help.

…

On Fri., 10 Jan. 2020, 08:41 Andrew Kirwin, ***@***.***> wrote: ...ok, I don't think this hasn't got any slower recently. But it does seem to be a downside of the architecture. In that each option is a component. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AAGRIF5Y6WFZQSQ6TQ6IFIDQ5BNH3A5CNFSM4KE7G322YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEITVLMI#issuecomment-573003185>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRIF7XH5SVO2TW5A37P23Q5BNH3ANCNFSM4KE7G32Q> .

[amk221]

Thanks,

I focused my investigation on the option components (I don't think it's anything to do with the parent component).

The only things that seem to have an impact are:

https://github.com/zestia/ember-select-box/blob/master/addon/components/select-box/option.js#L54-L60

and these bindings:

https://github.com/zestia/ember-select-box/blob/master/addon/templates/components/select-box/option.hbs#L2-L9

(i.e. commenting those things out speeds it up)

[robclancy]

I commented those things out and I still have the same issues. Also I have some slowdown on selecting an item. I need to test with the same dropdown but without all my changes to rule those out. But won't have time for a while.

[amk221]

Hmm! would it be possible for you to create a demo app? I would like to get to the bottom of this.

Here's the one I was using https://github.com/amk221/select-box-test/blob/master/app/templates/application.hbs

[robclancy]

I did a quick test with that. I went back to version 11 and it took around 1 second to open. Then back to current and it took 2 seconds. Measuring in profiling and only once, but that big of a difference I don't think I need to test more to know there is an issue. But it's really hard to know what.

I'm running on a faster pc now, with a ryzen 5 2600. And I know people use pretty slow things at the office which is my main concern. Right now I have hidden any performance issues (they get it when opening a modal, instead of when opening a select which is a nicer user experience).

Still seems like the main issue might be ember. And in other cases people have gotten around having so much to render in different ways. What I might try later is simply staggering the first render, where I add the options frame after frame to try stop the blocking.

It's also weird the beta did a bunch of polyfills etc whereas the current version you do things more up to date with ember but now the issue happens. So could be solely an ember issue.

[robclancy]

Okay so I thought production might also be a factor, it didn't change much locally for some reason but now that I have deployed with these updates the performance is far better. 200ms. Still slow but for how many coountries there are I would consider that pretty good.

So there might not actually be an issue, could just be part of local env with glimmer.

[amk221]

Thanks rob. That seems to be my conclusion too. It is slow in my local dev environment, and even more so with the dev tools open. And like you found, production builds seem ok.

The next step for the addon is to extend from @glimmer/component. Hopefully things will get better

[amk221]

I’ve updated to glimmer (see v14.0.0.beta) and the slowness persists. I will create an issue on the ember repo. I feel like it’s shouldn’t be this slow.

[amk221]

emberjs/ember.js#18798

[amk221]

Some progress on this
emberjs/ember.js#18861

[robclancy]

I tried it out and didn't see that much difference but I have my own hacks in there to help. Going to close this issue anyway since it isn't really a problem this addon can solve.

[amk221]

Just wondering if you've noticed any difference recently?

[amk221]

I tried ember-source 3.19 on the test repo mentioned above, and there was a huge improvement.

[robclancy]

I can't really check too easily now but what I could did seem a lot faster on 3.19.