analysis: severe performance issue when opening form

[Ross Brown]

I've seen comments in this NG that point to performance problems with
InfoPath, in which it goes to 100% CPU usage when opening a form and stays
there for a long time. I have this problem in spades, and have done some
analysis that I'd like someone from MS to read and comment on. Herein lies a
clue to the cause, perhaps?

[Warning: complex analysis with pictures and performance graphs from Process
Explorer!]

My InfoPath form uses +/- button controls to expand and collapse the
hierarchy of items in its view, using conditional formatting; the collapsed
nodes' content is not displayed ('style="display: none"'). The condition for
expansion is '@expanded="true"'. So, if the XML document element's children
all have '@expanded="false"', then the display is totally collapsed. If not,
some or all of the display is expanded and much more HTML gets generated by
the XSL transform. The following reference shows one node collapsed and one
expanded.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
IPpicFT.bmp]

Whether or not a long delay occurs when opening a form depends entirely on
the state of these '@expanded' attributes. In the sample form referenced
above, if both Class nodes have '@expanded="false"', then the form is ready
for editing as soon as it appears, with no significant delay. Not too
surprising - not much HTML. The Process Explorer graph shows a blip and then
smooth sailing.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicFF.bmp]

If the first Class node has '@expanded="false"' and the second has
'@expanded="true"', then the form is displayed quickly enough, but is ready
for editing only after about 45 seconds facing an hourglass cursor. The
Process Explorer graph shows sustained near-100% CPU usage for those 45
seconds.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicFT.bmp]

Now the trouble really starts: If the first Class node has
'@expanded="true"', then the user could grow a beard waiting for the
hourglass cursor to go away. The Process Explorer graph shows continuous
near-100% CPU usage and a sawtoothed VM usage curve that slowly increases for
a period of minutes to hours before it finally levels off and the form
becomes usable. Process Explorer also shows millions of page faults and tens
of thousands of context switches.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicTF.bmp]

What is happening during all this thrashing? Process Explorer's thread view
shows the main thread doing all the work, and each time I check its stack
traceback, it is beavering away inside MSHTML.DLL. Specifically, the bottom
of the traceback reads as follows:
msls31.dll!LsPointXYFromPointUV+0x120
msls31.dll!LsCreateLine+0xbb
mshtml.dll+0x712c0
The version of MSLS31.DLL is 3.10.349.0 and that of MSHTML.DLL is
6.0.2900.2523 (Windows XP Professional with Service Pack 2; InfoPath 2003
with Service Pack 1).

[You might be wondering, could this be the fault of the form template?
Actually, no: If I open a form with these two nodes collapsed, then click
the +/- buttons to expand them, the response is always immediate. But, if I
save that form with the nodes in their expanded state, I'll be in trouble the
next time I try to open it.]

 

[G. Tarazi]

Hi



I have performance problems with a form with large amount of c# event
handlers; it takes InfoPath exactly 20 seconds to bind the handlres to the
xml at runtime with a 100% CPU speed (in one of my forms) (even if the event
handlers are totally empty, even if I clear all the controls from the form,
and open the form totally empty with no xml, it still takes 20 seconds).



And as a workaround I decided to write my own event handlers (2 real event
handlers that are doing custom match to virtual event handlers).



Anyway, I don't think anyone cares about it from MS.



I was planning to use the +- to show and hide sections on the form, but
since you experienced that problem, I think I should cancel the idea

I've seen comments in this NG that point to performance problems with
InfoPath, in which it goes to 100% CPU usage when opening a form and stays
there for a long time. I have this problem in spades, and have done some
analysis that I'd like someone from MS to read and comment on. Herein lies a
clue to the cause, perhaps?

[Warning: complex analysis with pictures and performance graphs from Process
Explorer!]

My InfoPath form uses +/- button controls to expand and collapse the
hierarchy of items in its view, using conditional formatting; the collapsed
nodes' content is not displayed ('style="display: none"'). The condition for
expansion is '@expanded="true"'. So, if the XML document element's children
all have '@expanded="false"', then the display is totally collapsed. If not,
some or all of the display is expanded and much more HTML gets generated by
the XSL transform. The following reference shows one node collapsed and one
expanded.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
IPpicFT.bmp]

Whether or not a long delay occurs when opening a form depends entirely on
the state of these '@expanded' attributes. In the sample form referenced
above, if both Class nodes have '@expanded="false"', then the form is ready
for editing as soon as it appears, with no significant delay. Not too
surprising - not much HTML. The Process Explorer graph shows a blip and then
smooth sailing.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicFF.bmp]

If the first Class node has '@expanded="false"' and the second has
'@expanded="true"', then the form is displayed quickly enough, but is ready
for editing only after about 45 seconds facing an hourglass cursor. The
Process Explorer graph shows sustained near-100% CPU usage for those 45
seconds.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicFT.bmp]

Now the trouble really starts: If the first Class node has
'@expanded="true"', then the user could grow a beard waiting for the
hourglass cursor to go away. The Process Explorer graph shows continuous
near-100% CPU usage and a sawtoothed VM usage curve that slowly increases for
a period of minutes to hours before it finally levels off and the form
becomes usable. Process Explorer also shows millions of page faults and tens
of thousands of context switches.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicTF.bmp]

What is happening during all this thrashing? Process Explorer's thread view
shows the main thread doing all the work, and each time I check its stack
traceback, it is beavering away inside MSHTML.DLL. Specifically, the bottom
of the traceback reads as follows:
msls31.dll!LsPointXYFromPointUV+0x120
msls31.dll!LsCreateLine+0xbb
mshtml.dll+0x712c0
The version of MSLS31.DLL is 3.10.349.0 and that of MSHTML.DLL is
6.0.2900.2523 (Windows XP Professional with Service Pack 2; InfoPath 2003
with Service Pack 1).

[You might be wondering, could this be the fault of the form template?
Actually, no: If I open a form with these two nodes collapsed, then click
the +/- buttons to expand them, the response is always immediate. But, if I
save that form with the nodes in their expanded state, I'll be in trouble the
next time I try to open it.]

--
Ross Brown
Advisor, IS Technical Software Development
Computer Sciences Corporation
Ottawa, Ontario, Canada

 

[Brian Teutsch [MSFT]]

Thanks for the detailed description of the issue. Unfortunately, there's
nothing in there that could explain why your form is slow in one case but
not another. Could you pass along your form to me? There's a part of my
email address that requires removing.

Thanks,
Brian

I've seen comments in this NG that point to performance problems with
InfoPath, in which it goes to 100% CPU usage when opening a form and stays
there for a long time. I have this problem in spades, and have done some
analysis that I'd like someone from MS to read and comment on. Herein
lies a
clue to the cause, perhaps?

[Warning: complex analysis with pictures and performance graphs from
Process
Explorer!]

My InfoPath form uses +/- button controls to expand and collapse the
hierarchy of items in its view, using conditional formatting; the
collapsed
nodes' content is not displayed ('style="display: none"'). The condition
for
expansion is '@expanded="true"'. So, if the XML document element's
children
all have '@expanded="false"', then the display is totally collapsed. If
not,
some or all of the display is expanded and much more HTML gets generated
by
the XSL transform. The following reference shows one node collapsed and
one
expanded.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
IPpicFT.bmp]

Whether or not a long delay occurs when opening a form depends entirely on
the state of these '@expanded' attributes. In the sample form referenced
above, if both Class nodes have '@expanded="false"', then the form is
ready
for editing as soon as it appears, with no significant delay. Not too
surprising - not much HTML. The Process Explorer graph shows a blip and
then
smooth sailing.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicFF.bmp]

If the first Class node has '@expanded="false"' and the second has
'@expanded="true"', then the form is displayed quickly enough, but is
ready
for editing only after about 45 seconds facing an hourglass cursor. The
Process Explorer graph shows sustained near-100% CPU usage for those 45
seconds.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicFT.bmp]

Now the trouble really starts: If the first Class node has
'@expanded="true"', then the user could grow a beard waiting for the
hourglass cursor to go away. The Process Explorer graph shows continuous
near-100% CPU usage and a sawtoothed VM usage curve that slowly increases
for
a period of minutes to hours before it finally levels off and the form
becomes usable. Process Explorer also shows millions of page faults and
tens
of thousands of context switches.
[reference: http://www.magma.ca/~awolsp/infopath/images/pics.zip, file
PEpicTF.bmp]

What is happening during all this thrashing? Process Explorer's thread
view
shows the main thread doing all the work, and each time I check its stack
traceback, it is beavering away inside MSHTML.DLL. Specifically, the
bottom
of the traceback reads as follows:
msls31.dll!LsPointXYFromPointUV+0x120
msls31.dll!LsCreateLine+0xbb
mshtml.dll+0x712c0
The version of MSLS31.DLL is 3.10.349.0 and that of MSHTML.DLL is
6.0.2900.2523 (Windows XP Professional with Service Pack 2; InfoPath 2003
with Service Pack 1).

[You might be wondering, could this be the fault of the form template?
Actually, no: If I open a form with these two nodes collapsed, then click
the +/- buttons to expand them, the response is always immediate. But, if
I
save that form with the nodes in their expanded state, I'll be in trouble
the
next time I try to open it.]

--
Ross Brown
Advisor, IS Technical Software Development
Computer Sciences Corporation
Ottawa, Ontario, Canada

 

[Ross Brown]

Thanks for the detailed description of the issue. Unfortunately, there's
nothing in there that could explain why your form is slow in one case but
not another. Could you pass along your form to me? There's a part of my
email address that requires removing.

Thanks for the offer. I'll hold off for now, as I have found one laptop
where the performance problem does *not* occur. There may be some
configuration difference that I should analyze before asking you to pick
things apart.

Cheers,
Ross