{"id":127,"date":"2018-01-17T12:41:53","date_gmt":"2018-01-17T20:41:53","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/performance-considerations-with-powerapps\/"},"modified":"2024-07-31T14:36:47","modified_gmt":"2024-07-31T21:36:47","slug":"performance-considerations-with-powerapps","status":"publish","type":"power-apps","link":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/performance-considerations-with-powerapps\/","title":{"rendered":"Performance considerations with PowerApps"},"content":{"rendered":"

Performance is a top priority for the PowerApps engineering team. There are major efforts currently underway to improve performance around app load time, the designer experience in PowerApps Studio, connectors response time\u2026etc. While the infrastructure will continue to improve, there are a number of things you can do as an app maker to improve the performance of your app. In this blog post I will touch on few concepts that are universal when talking about building native or web apps but apply equally well to apps built with PowerApps.<\/p>\n

Loading Data<\/h2>\n

PowerApps has two types of connectors: standard connectors and custom connectors. There are over 160 standard connectors<\/a> today and the list is growing. There are two types of standard connector depending on the shape of data returned. The first type returns tabular data. SharePoint, Common Data Services, SQL are examples of tabular data sources where the data returned is in the form of a table. The other type of connector work with function based data sources. Office365, Twitter, Outlook connector are examples of function-based connectors where data is returned with a specific schema.\u00a0 This blog will focus on tabular connectors but the concepts apply as well to the other type of connectors. I will show how some trade offs in the way we load and store data can lead to significant performance improvement and thus improved user experience. For this example, we will use SQL as our data source. We will work with 2 tables: Project & Owners.\u00a0 Our UI is simply a gallery bound to the project table. Each item in the gallery will show the start\/end dates, project name and owner. We will explore 2 ways of wiring this simple scenario and compare the resulting experience and performance.<\/p><\/blockquote>\n

Option 1:<\/strong><\/p>\n

In this example, we will bind our gallery Items property directly to the data source [dbo].[Project]. The project table has a foreign key linking it to the Owner table.\u00a0 So in order to display the actual owner of a project, we will need a LookUp from each of the project into the Owner table as follow:<\/p>\n

\"graphical<\/p>\n

When the app is loaded,\u00a0 34 calls were made through the SQL connector and took 6.582 seconds to complete (broadband connection). Taking a closer look at the timeline as seen in a fiddler network trace, we see that a call to fetch the Project table , then each visible gallery item (and few more) triggered a call to the owner database to fetch owner information for that item.<\/p>\n

\"chart\"<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"text\"<\/p><\/blockquote>\n

Here is how the loading experience looks like. Notice the blank screen and loading artifacts for the Owner name.<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"SQL\"<\/a><\/p><\/blockquote>\n

Option 2:<\/strong><\/p>\n

In this example, we will first collect the tables into local collections. We will bind the gallery Items property to the local collection and use the owner collection for LookUps. On the OnVisible event, we add the following statements:<\/p>\n

\"\"<\/p>\n

\"graphical<\/p>\n

This is the network traces when the app starts.<\/p>\n

\"\"<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"\"<\/p><\/blockquote>\n

As you can see only 2 calls are being made. The first call fetches a maximum of 500 items from the Project Table and similiarly the 2nd call will do the same for the owner table.\u00a0 Because the LookUp used in each item is referencing the local in-memory collection, we don’t additional network calls. Overall, the duration of these 2 calls is 3.170 seconds. That is more than 50% faster than the above example.\u00a0 Notice how the data is rendered immediately after the loader animation is done.<\/p>\n

\"ClearCollect\"<\/a><\/p>\n

Remarks<\/strong><\/p>\n