Re: [Xsltforms-support] IE8 Performance on XSLTForms beta-3
Brought to you by:
alain-couthures
Menu
▾
▴
Re: [Xsltforms-support] IE8 Performance on XSLTForms beta-3
|
From: <fr...@fl...> - 2010-12-23 12:08:48
|
Hi all,
The 471 version indeed boosted performance for my application with a
10000 line instance. Under IE8 the loading time is now 40 seconds, too
much for operational use, but that is coming within reach.
The amazing part is the performance under FF: 3.6 seconds. More than a
factor 10 faster. Does anyone have a clue why that is?
Good days!
Fred
Citeren Grégoire COLBERT <gco...@gm...>:
> Hi!
>
> I've read the discussion but cannot sort this out in my mind : is this
> performance issue, that you are talking about, due to the fact that we
> cannot refresh a single model? I mean the emptiness of the
> "XFModel.prototype.refresh" function at the moment. Or is it not related?
>
> Thanks!
> Grégoire
>
>
> Le 21/12/2010 11:37, Santosh Chandak a écrit :
>> Thanks Alain. For our form, we can not remove // from all the places
>> because we have nested xml.
>> Regarding the solution to refresh select part of the page, I could
>> implement it by passing hint on selecting the parent node for a
>> particular form control and it is working great. I simply pass a
>> number (depending on all the dependencies) on focus event which would
>> help in determining the parent node to be refreshed.
>> Below is the code snippet -
>> A trigger on form has -
>> <xf:setvalue ev:event="DOMActivate"
>> ref="instance('datapad')/@parentIndex" value="4"/>
>>
>> And in xsltforms.js -
>> XFControl.prototype.focus has -
>> xforms.selectedElement = this.element;
>>
>> refresh method has -
>>
>> var parentIndex = Util.getParentIndex(); // returns
>> instance('datapad')/@parentIndex
>> if(!this.selectedElement || parentIndex == "-1") {
>> this.selectedElement = this.body; // Can be optimized further
>> } else {
>> for(var i = 0; i < parentIndex; i++) {
>> this.selectedElement = this.selectedElement.parentNode;
>> }
>> }
>> this.build(this.selectedElement,
>> (this.defaultModel.getInstanceDocument() ?
>> this.defaultModel.getInstanceDocument().documentElement : null), true);
>> Util.setParentIndex("-1");
>>
>>
>> All we need to do is pass appropriate parentIndex from the form and it
>> should resolve the performance issues caused by refreshing the entire
>> page. I hope something on these lines can be added to the xsltforms
>> library.
>>
>>
>>
>>
>>
>> On Fri, Dec 17, 2010 at 1:00 AM, COUTHURES Alain
>> <ala...@ag... <mailto:ala...@ag...>>
>> wrote:
>>
>> Hi Santosh,
>>
>>> I think reducing use of // and using multiple models might be
>>> able to help but would not resolve the issue when form is big.
>>>
>> This can resolve this issue when data is big...
>>
>>> In our case, we might not be able to test with multiple models
>>> unless nested models are supported (I think nested models are not
>>> supported in Xforms 1.1)
>>>
>> I don't understand what you mean with nested models but nested
>> forms are considered for next XForms versions.
>>
>>>
>>>
>>> I debugged the code and came to know the main reason for
>>> XSLTForms being slow is because for every change, it tries to
>>> refresh all the elements on the page. The exact location of
>>> problem is below line in the refresh method -
>>>
>>> this.build(this.body, (this.defaultModel.getInstanceDocument() ?
>>> this.defaultModel.getInstanceDocument().documentElement : null),
>>> true);
>>>
>>>
>>>
>>> Refresh method passes the entire HTMLBodyElement (this.body =
>>> xforms.body = HTMLBodyElement ) every time anything is changed.
>>> The build method gives recursive calls on all its children.
>>>
>>> For a big form, for simple operations like change in data of a
>>> textbox, I am seeing lots of recursive calls to the build method
>>> and thousands of calls to Xpath methods etc.
>>>
>> Yes, there is no list of elements to be checked and refreshed when
>> necessary. This can be added but this is not an easy change. The
>> number of XPath methods calls should be reduced when reducing the
>> use of //: I should check it myself but I'm almost sure that it's
>> very bad for dependencies and, probably, every expression is
>> reevaluated each time. Don't ever use //, this is my most precious
>> advice...
>>
>>>
>>>
>>>
>>>
>>> I think this problem can be solved with selecting the right HTML
>>> Element every time we give call to refresh method
>>>
>>>
>>>
>>> * Refresh HTMLBodyElement only when entire form is loaded
>>> * For every action, we know where the Focus/blur happened,
>>> refresh only its appropriate parent HTML element
>>> * Binds can be handled separately. Cases where we need to
>>> refresh other elements can be handled separately
>>>
>> There might be reverse lists of dependencies to directly point
>> elements to be refreshed but they wouldn't be easy to store with
>> the native XML architecture.
>>
>>>
>>>
>>> This should guarantee that only a select part of the page is
>>> considered for refresh. I have tried to do it and in fact I can
>>> see that it can be achieved, just need to determine how many
>>> levels to go up and select the appropriate HTML parent Element.
>>>
>> Sorry, I don't think that it would be a correct approach. This
>> might work for your form but not for all.
>>
>> Maybe declaring, with extra attributes, some sort of groups of
>> elements to be refreshed together or allowing to declare that this
>> element has to be refreshed only when a user-defined event is
>> dispatched might help.
>>
>> Thanks!
>>
>> -Alain
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how
>> to connect the dots, take your collaborative environment
>> to the next level, and enter the era of Social Business.
>> http://p.sf.net/sfu/lotusphere-d2d
>>
>>
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>
|
