I'm hoping there's some kind of planned performance improvement work on the gallery control, but posting this, in case there isn't.
At present, the gallery control is incredibly clunky/laggy when scrolling any faster than what I'd consider to be "unreasonablly slow". The behavior is
I will note:
I'm attaching a video of this behavior. While the lag you see might be "acceptable", it's not a great user experience on any platform. I understand that the gallery is probably working as designed for keeping resource utilization low on mobile devices, however, since this can be reproduce on mobile, too, I'm asking that Microsoft improve this.
Hi @pmcgurn01 ,
How many records are there for your data source?
About how to improve performance in PowerApps, you can also refer to:
https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/performance-tips
https://powerapps.microsoft.com/en-us/blog/performance-considerations-with-powerapps/
Regards,
Mona
I had a whole nice reply typed up, but every time I post something in this community, it fails the first time with an "unexpected error, contact your system administrator", and if I didn't copy what I wrote before submitting, it's lost.
Answers to your reply:
I have the same performance issue and my gallery items are based on a local collection. Scrolling is worse than what is picture in the above video example. Has anyone found a solution for the scrolling issue?
I also am having this issue.
It is not based on number of records at all as I only have about 45 right now.
I have also tried the same data in a local collection to see if that made a difference, and it did not.
This forum is infuriating. Every time I post, it loses the original and I have to re-write it. Having to save my original content to a notepad just in case I hit the "unexpected error occurred" failure makes me post less.
Rant on that, over. Now on to my reply.
It's definitely not caused by network latency. I profiled it in Chrome, and there's a clear lag in scroll performance even when not calling for data from the data source via network. So that rules out the cached local collection vs. data source binding conversation entirely. My DS and use case for this screen are too big to cache anyways.
The screen I'm testing this with has a gallery that contains 10 UI elements in the template, where 7 are DS-bound and 3 are static images/labels. Of the 7, 5 are labels and 2 are read-only radio buttons. The app checker shows no warnings related to anything on the app other than warnings on accessibility text.
So, I really hope Microsoft is working on improving this performance, because it's unusable at scale and making me reconsider my decision to use the PowerApps platform to deploy apps within my company.
I have found that if there are any processes running in the back ground or from a timer the scroll latency increases considerably. Even with no processes in the back ground and less than 100 records in a collection performance lags when scrolling. My clients were using Access database front ends linked to SQL databases and the scrolling performance was much better.
Access DB's having better performance than Azure SQL is pretty tragic.
Is Microsoft doing any work on this issue? Makes for a very poor user experience when user scrolls and then has to wait several seconds for the controls to render
Bump on this thread. The issue is all over the place. Especially worsens with nested galleries... apps are nearly non-functional. Both CPU and Memory consumption jump through the roof on local machines while scrolling.
I'm caching all data into a local collection like everyone here... There is no pattern suggestion or dev best practice to alleviate this. This is a performance bug with the platform as a whole.
Need MS eyes on this please.
Stay up tp date on the latest blogs and activities in the community News & Announcements.
Mark your calendars and join us for the next Power Apps Community Call on January 20th, 8a PST
Dive into the Power Platform stack with hands-on sessions and labs, virtually delivered to you by experts and community leaders.
User | Count |
---|---|
198 | |
173 | |
62 | |
33 | |
32 |
User | Count |
---|---|
338 | |
271 | |
105 | |
71 | |
58 |