MultiSelect with VirtualScroll filtering is too slow after scrolling far down

[julrich-bee360]

Describe the bug

When using the MultiSelect component with VirtualScroll with many options, filtering the list of options is very slow after scrolling far down in the list, which brings up the "Page(s) Unresponsive" dialog.

The filtering is fast when not scrolling at all or only scrolling a few hundred entries. However, the further you scroll, the slower it gets and after some point, it brings up the "page unresponsive" dialog.
I also noticed that it's only the very first character which is slow. After handling the first character entering further characters works smoothly.

Tested it in Chrome (132.0.6834.111, arm64) and Opera (115.0.5322.119, arm64).

It's also reproducible on the PrimeNG documentation page: https://primeng.org/multiselect#virtualscroll

Pull Request Link

No response

Reason for not contributing a PR

• Lack of time
• Unsure how to implement the fix/feature
• Difficulty understanding the codebase
• Other

Other Reason

No response

Reproducer

https://stackblitz.com/edit/uxrdq4sr

Environment

• macOS 14.6.1
• MacBook Pro
• Apple M2 Max
• 96 GB RAM

Angular version

19.0.1

PrimeNG version

v19

But v17 and v18 are also affected (tested on the PrimeNG documentation page).

Node version

No response

Browser(s)

No response

Steps to reproduce the behavior

1. Click on "Select Cities"
2. Use the mouse to scroll far down in the list (e.g. to Item #66684) using the scroll bar
3. Click into the filter input box
4. Type something

Expected behavior

The list is filtered quickly, no matter how far the user scrolled in the list before.

[github-actions]

Due to PrimeTek's demanding roadmap for PrimeNG, this issue is available for anyone to work on. Make sure to reference this issue in your pull request. ✨ Thank you for your contribution! ✨

[AlexFHer]

The problem is the method placed in the scroller, the more you scroll down, the worse it gets. I can assume that is because the way virtual scrolling is managed. I think this should be something the core team must check internally, quite a big change.

if that method is not called it's fast.