Components: Autocomplete slow to update with large data sets after material beta 12

[micahwood]

Bug, feature request, or proposal:

When displaying an autocomplete list with a large number of options it is slow to display. It appears that this is caused by 2 event listeners being created for each item in the list. This slowness started after updating to beta 12.

You can see the large number of event listeners being set up if you open the Chrome dev tools and set the logging level to verbose.
[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

What is the expected behavior?

Similar performance when using autocomplete with 200+ data sets to older versions of material.

What is the current behavior?

Rendering an autocomplete with a large number of options has a delay, it is even longer when the dev tools are open due to the large number of event listeners being created causing logs to be written to the console

What are the steps to reproduce?

Open dev tools, set console logging to verbose and click the "Click to toggle autocomplete" button .
You can also see the behavior by filtering the list, type anything to shorten the length of the list, then clear the input and new event listeners will be created again for each item in the list causing additional slowdown.
https://plnkr.co/edit/QhlHy7FrlvQbDeRfncCo?p=preview

What is the use-case or motivation for changing an existing behavior?

Improve performance. Is it not possible to have a single event listener on the parent that catches click events that bubble up? If not do 2 event listeners need to be created for each item in the list?

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular: 4.4.4
Material: beta.12
All browsers

Is there anything else we should know?

Event handler times on beta.11
Clearing out the input box, causing all items to be displayed again
[Violation] 'input' handler took 187ms
Clicking the button to display the autocomplete
[Violation] 'click' handler took 246ms

Event handler times on beta.12 doing the same actions
[Violation] 'input' handler took 1347ms
[Violation] 'click' handler took 1048ms

[radoslavpetranov]

I just spent 2 hours trying to figure out if I broke something performance-related somewhere after updating from material beta.8 to beta.12. I was comparing the performance between the app on prod and the newly updated dev version and my country autocomplete is definitely causing noticeable lag in beta.12.

I have some form arrays where each internal form object contains a country autocomplete (so a whole bunch of options) and adding a few of these autocompletes is making the page really slow.

I also see thousands upon thousands of these messages

[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

[dushkostanoeski]

Will this be addressed in the next beta?

[johnchristopherjones]

5113 seems related. I didn't see this problem in beta.10 but it appears to be quite nasty in beta.12.

[kylecordes]

If you're willing to load the numerous options on demand (rather than trying to put them all in the UI at once), you can get excellent results with unlimited size lists. Code that does so, and demo, link below.

https://github.com/OasisDigital/angular-material-obs-autocomplete

https://oasisdigital.github.io/angular-material-obs-autocomplete/

[mikeomeara1]

Hey guys, hate to "me too" but this is really become a problem and our users are clamoring...any idea when this might get looked at?

We have some Autocomplete's that are taking 10+ seconds to initialize (which wasn't happening ~Beta12). We're at a point where we’re facing having to yank Autocomplete if we can’t get this fixed.

As always, appreciate all of your hard work and please let me know if there is anything we can do to assist.

[crisbeto]

@mikeomeara1 do you know approximately how many options you're rendering inside the autocomplete for it to take so long?

[mikeomeara1]

@crisbeto Generally speaking < 1000 works OK. Anything more than that there is anywhere from a perceptible "screen freeze" to a full 5-10 second gap while it loads up. Obviously the more you add the worse it gets.

We didn't notice this issue (even with our huge lists) pre v5.0.0. I should also say that when there is a huge number of items SOME delay is inevitable...which we can live with. It's just that that delay has gotten much more acute.

[crisbeto]

At what point are you running into the freeze? When loading up the view or when attempting to open the autocomplete panel?

[mikeomeara1]

On first showing the autocomplete, the delay is before the autocomplete panel is open (and once it's un-stuck, opening the panel is quick). However we're also seeing the same (or more) delay when we manually re-trigger the autocomplete panel after the user makes their first selection.

I can send you a video if there is a way for me to send it to you directly (e.g. not have to post it)

[crisbeto]

A video might not be great for debugging. I put together this demo for testing things out and there definitely is a noticeable delay both when rendering the autocomplete and when opening it. Are you seeing something similar in your case?

As for improving the performance, we can relatively easily add the ability to have your mat-autocomplete be attached to an ng-template which will help with the initial load, because it won't render the options when they aren't being shown. Improving the opening of the panel is a different story, because we still have 2000+ components that need to be instantiated.

[mikeomeara1]

Fair enough. OK so, from what I can see here, this is running MUCH faster than what I'm seeing...this is how it USED to work. Even when I up the items to 10,000...it works how I would expect. So, that means one of two things:

1. Something got fixed between v5.0.0 and v5.0.1
2. I have something else broken here that happened when we upgraded from Beta.12 to 5.0.0

I'll try and upgrade here soon and report back if it solves the problem.

[crisbeto]

I don't think much has changed in the autocomplete between the 5.0.x versions for it to have any impact on performance. My guess is that your template might be a bit more complicated than my demo.

[mikeomeara1]

It's almost exactly the same as yours actually...just with an onSelectionChange and async pipe.
https://gist.github.com/mikeomeara1/facf01de71bed795b49457ae8bfdde23

I just pulled your demo into my app and it's doing the same thing...taking a VERY long time to load up and reopen. Curious.

[apoorv-techelogy]

waiting for it to get resolved as soon as possible

[mikeomeara1]

@crisbeto I have some good news. Upgrading from v5.0.0 to v5.1.1 solved this problem. All of our autocomplete and select's are now working as we would expect (and the delays when rendering or opening have gone from 8-10 seconds down to <1 second again).

So, whatever was done during that time seemed to resolve the issue (at least for us).

As usual, truly appreciate your help.

[Swoox]

@mikeomeara1 cheers this solve the issues I had.

[EvaristoPerez]

@mikeomeara1 thanks form my side too! big help. Now @crisbeto I think the changes that fixes this are more related to 5.1.0 than 5.1.1 that is why maybe you did not find relationships. So there at 5.1.0 on the ripple side it is mentioned that they fixed to optionally register those events mentioned in the original problem from @micahwood . Anyways thanks evryone big help for me though.