InfoPath Dev

Hi All,

I have read a number of articles on various news groups about poor performance when loading InfoPath forms. Which is being attributed to large numbers of views, lots of conditional formatting or the binding of c# event handlers.

I too am experiencing poor performance and thought I would share my investigation findings with you all in the hope a solid understanding / explanation can be obtained.

My environment. An InfoPath form with 3 views. 4 webservices as secondary data sources to populate drop downs with a maximum of 20 items in each drop down. No role settings. No conditional formatting. 1 button control with a c# event handler. The forms are digitally signed. Published within Sharepoint.

After booting up each day, the first time each type of InfoPath form (i.e. discharge form or transfer form) is loaded, the loading time takes around 7 seconds. All subsequent loadings of the form take around 3 seconds. This is consistent until the machine is rebooted.

From my understanding the InfoPath cache processing occurs every time an InfoPath form is opened. Please note, during the first load the cache files are NOT updated. So why does the first opening of an InfoPath form each day take a significant amount of time longer?

Thanks to this article http://blogs.msdn.com/asanto/archive/2004/05/18/133796.aspx) which talks about programmatically caching InfoPath templates using Application.CacheSolution. I implemented a simple solution: when the user logs on, the InfoPath form templates are cached locally on the user#%92s PC. The outcome of this forced caching is the time taken for the first loading of the InfoPath form is reduced from 7 seconds to 5 seconds. I acknowledge this is a good improvement but I did expect the performance to drop to at least 3 seconds – like all subsequent opening of the InfoPath form.

Does anyone have any concrete understanding as to why / what is occurring. I cannot believe a straight forward InfoPath form takes 3 seconds to load.

thanks for your time.
kind regards
Scott

Hi Scott,

Great post! Yes, InfoPath has performance issues as a result of the reapply algorithm it is using to display the xml. Believe me, this is a huge issue. We have been battling performance for several forms over the past year. The good news is that most of the performance issues can be mitigated.

First, some comments: number of views shouldn't be an issue since reapply algorithm only binds to default view on load. Conditional formatting could be a problem, but tends to help rather than hinder (since you can hide stuff that has to be bound... :). Event handler issues should be completely mitigatable by writing smarter code to not do a lot of processing (or percolate events up the DOM). In addition, if at all possible, you should not be blocking on data connections to populate the form. Sometimes this is unavoidable, but in general, consider doing this only when they click on a UI element. That will improve OnLoad perf.

You could cache the 20 items for each drop down in a secondary data source in the form and add a button to "refresh" from Web service, or use one Web service to get all of your data. Without more perf analysis on the Web services, though, it might not be a huge win, but please try to retest with static dropdowns and see what the difference is. If it's large, then you'll want to offload the calls to a button or after the form is loaded.

One big issue for OnLoad perf is the size of XML file and number of elements in view. How big is the XML file? How many nodes on your view? Have you considered reducing the number of elements you are showing? That should help speed things up.

I look forward to hearing about your experiments,

Typically, what we do is to reduce the number of elements bound to the view.


Patrick Halstead [InfoPath MVP]
InfoPathDev

Hi Patrick,

Thanks so much for an informative post. I am away for the next few days, so will update you of my findings on my return.

Just one quick question. What does this mean?
In addition, if at all possible, you should not be blocking on data connections to populate the form. Sometimes this is unavoidable, but in general, consider doing this only when they click on a UI element. That will improve OnLoad perf.

thanks again, Scott

Hi Scott,
If you are querying a Web service or asynchronous data source on load it can result in a delay or time out. Rather than query the Web service on load, you can do so programmatically later. There is in fact a setting to connect on load of the form. My suggestion is to not do this and see how much on load perf improves. If it improves a lot (to the point where it is acceptable), it's probably a sign to delay load the data (as opposed to blocking on load for it). Delay load is not going to work if you have data that you must display on load and the only way to get at it is to query a data source. However, if the data can be hidden, or defaulted, or ellipsis-marked, then you can add a UI control like a button to then force the load. This is probably a better user experience since they expect the form to load fast (and don't know it's blocking on secondary data) but when they click on a button, they know it's going off to fetch data and so are more patient and willing to wait.

Patrick Halstead [InfoPath MVP]
InfoPathDev

Hi Patrick,

OK here goes with some results. Based on a freshly built fully patched server 2003 box.

Going back to basics. Using blank InfoPath forms created under two scenarios.

1. Let#%92s design the form through InfoPath (not visual studio).
Creating a simple blank form. Published to a local drive. Clicking on the published xsn will open the InfoPath form immediately. I can#%92t even say one second expires before InfoPath is launched and the form is displayed.

2. Let#%92s create the same type of form using Visual Studio.
Creating a simple blank form. Published to a local drive. Clicking on the published xsn will take just short of two seconds to launch InfoPath and display the form.

Now the only significant difference I know between these two xsns (InfoPath vs visual studio created) is a DLL within the Visual Studio created xsn. So how does such a significant performance difference occur?

Next test. Adding a drop down list to each form above. The drop down list is populated by a webService secondary data connection. The webService only returns 2 values. The webService automatically executes on form load.
1. The InfoPath created form performance remains the same.
2. The Visual Studio created form performance remains the same.

Next test. The webService now returns 1000 values.
1. The InfoPath created form performance remains the same.
2. The Visual Studio created form performance remains the same.

Next test. The secondary data connections now DO NOT automatically execute on load. Thus, just non processing forms opening again.
1. The InfoPath created form performance remains the same.
2. The Visual Studio created form performance remains the same.

So to summarise with the above tests. WebService data connections are not affecting performance at all. Performance remains consistent. However on identical forms, an InfoPath created form launches significantly quicker (not even one second) compared to a Visual Studio form (approx two seconds). How come???

Moving onto my discussed real world form.
template.xml = 3kb
manifest.xsf = 58kb
view xsl = 47kb
view contains – 17 text boxes, 4 date pickers, 2 option buttons, 1 check box. All controls are contained within 3 sections. Each control has text above it.

The webService data connections now do not automatically execute on load. The performance stats are:
First time load of the form – remains at seven seconds.
Subsequent loading of the form – drops from around three seconds to about two seconds.

I interpret these results;
• Confirmation that webService secondary data connections do have a performance impact when automatically loaded on form load.
• That the number of controls on this form is not affecting performance. Because the blank form also took approx two seconds to load.

Therefore, I am still unable to answer the question of why a visual studio created InfoPath form has reduced opening performance compared to an InfoPath created form.
Can anyone confirm this performance on their systems? And maybe explain why?

Kind regards
Scott

Hey Scott,
Thanks for the enlightening post. I would love to see stopwatch second counts though on the various methods. I think that there might be some confusion on the lazy web service calling. My point is that it should speed up on load since it isn't blocking on the web service. Are you saying that it's the same amount of time to load a form that has no prepop and a form that gets 1000 items from a WS? That doesn't seem logical. Maybe 1000 is too small, but I would expect some penalty here. Perhaps it is imperceptible.

Anyway, I am left thinking that your perf pain must be due to the loading of the Primary Interop Assembly for InfoPath ... I guess this is a tax of using .NET in InfoPath.

Patrick Halstead [InfoPath MVP]
InfoPathDev

Hi Patrick,

Sorry for the long delay in replying, I have been out of the office for the last week.

I am glad you suggested stopwatch times. Some good results. OK here goes …

The tests were in the format; reboot the machine. Run 4 successive opening and closings of the same form. Reboot the machine (R). Run another 4 successive opening and closings of the same form. All times are in seconds.

The first line is the InfoPath IDE created blank form.
The second line is the Visual Studio created blank form.
.…1…|..…2…|…3.…|..…4…|.R.| .…1…|..…2…|…3.…|..…4…|All AV.|.Av Not inc 1.|
2.94 | 0.75 | 0.81 | 0.70 | R | 5.00 | 0.78 | 0.75 | 0.65 | 1.55 | 0.74 |
6.80 | 1.50 | 1.39 | 1.44 | R | 7.00 | 1.50 | 1.49 | 1.25 | 2.80 | 1.43 |

The first line is the InfoPath IDE created blank form, webService returning 2 records.
The second line is the Visual Studio created blank form, webService returning 2 records.
.…1…|..…2…|…3.…|..…4…|.R.| .…1…|..…2…|…3.…|..…4…|All AV.|.Av Not inc 1.|
3.25 | 0.93 | 1.00 | 0.80 | R | 3.60 | 0.76 | 0.89 | 0.83 | 1.51 | 0.87 |
6.30 | 1.55 | 1.61 | 1.62 | R | 6.26 | 1.37 | 1.55 | 1.56 | 2.73 | 1.54 |

The first line is the InfoPath IDE created blank form, webService returning 1000 records.
The second line is the Visual Studio created blank form, webService returning 1000 records.
.…1…|..…2…|…3.…|..…4…|.R.| .…1…|..…2…|…3.…|..…4…|All AV.|.Av Not inc 1.|
4.75 | 1.05 | 0.93 | 1.04 | R | 4.93 | 1.11 | 0.94 | 0.87 | 1.95 | 0.99 |
7.51 | 1.75 | 1.99 | 1.62 | R | 6.68 | 1.69 | 1.55 | 1.43 | 3.03 | 1.67 |

Therefore, as you expected, this does clearly show there is a consistent increase in form average opening time (based on the average not including the 1st opening time) when firstly the webService is added, then as the webService return records increase.

Moving on to my real world example;
The first line is the Discharge form with webServices onload.
The second line is the Discharge form with NO webServices onload.
.…1…|..…2…|…3.…|..…4…|.R.| .…1…|..…2…|…3.…|..…4…|All AV.|.Av Not inc 1.|
18.12 | 2.43 | 2.81 | 2.75 | R | 14.93 | 2.51 | 2.44 | 2.87 | 6.11 | 2.64 |
12.12 | 2.69 | 2.37 | 2.05 | R | 14.30 | 2.31 | 2.12 | 2.30 | 5.03 | 2.31 |
Once again showing there is a performance difference with the webServices executing on load.

Finally, programmatically caching InfoPath templates using Application.CacheSolution before the 1st opening of the InfoPath form.
http://blogs.msdn.com/asanto/archive/2004/05/18/133796.aspx)
The first line is the Discharge form with webServices onload.
The second line is the Discharge form with NO webServices onload.
.…1…|..…2…|…3.…|..…4…|.R.| .…1…|..…2…|…3.…|..…4…|All AV.|.Av Not inc 1.|
7.99 | 2.57 | 2.76 | 2.81 | R | 9.80 | 2.87 | 3.01 | 2.75 | 4.32 | 2.80 |
6.99 | 2.62 | 2.44 | 2.09 | R | 7.63 | 2.19 | 2.49 | 2.50 | 3.62 | 2.39 |
Once again showing there is a performance difference with the webServices executing on load.
In addition, showing an initial performance gain occurred on the 1st opening using the CacheSolution, despite the cache files NOT being updated in any way. Lets not forget though, still not to the expected performance of a non 1st opening time.

Thus these stopwatch figures compared to my human stopwatch :) figures do show performance differences occur based on the webService record numbers and execution place.

Sadly this does not really shed any new light on what is causing the delay and the PIA gets the blame !!!! Shame, I wanted to give a concrete answer as to why these performance differences are occurring between blanks forms created using the InfoPath IDE vs the Visual Studio IDE.

thanks for your continued input Patrick,
Kind regards,
Scott