xsltforms-support

[Xsltforms-support] conflict between subforms and the profiler?

[C. M. Sperberg-M. <cm...@bl...>]

I've encountered an unexpected behavior in 1.0RC.  I first encountered
it in one of my own forms, but the simplest way to recreate it may be:

(1) Load the writers.xml example from the 1.0RC distribution, or from

    http://www.agencexml.com/xsltforms/writers.xml

(2) Click Show Books and Hide Books a few times.

(3) Click Profiler.

This ought in normal operation to produce a profile showing the profiler
information we have all come to love.  What it produces instead, at the 
moment, is a Javascript error message saying 

  XSLTForms Exception
  --------------------------

  Error dispatching event 'xforms-model-construct' :

  xforms-link-exception

This makes it hard to put hard numbers on the results of using subforms,
but as far as I can tell, moving from Beta3 to 1.0RC has reduced load time
for some documents I am working with by 25 to 30%, and reduced time
for processing some parts of the documents by 15 or 20%, and changing
to subforms reduces the load time by another 25%.  So the new version
of the form I'll be able to make available to my users is about twice as 
fast, on long documents, as the current version.

Well done, Alain!!
 
-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] conflict between subforms and the profiler?

[C. M. Sperberg-M. <cm...@bl...>]

On Jun 26, 2012, at 7:38 PM, C. M. Sperberg-McQueen wrote:

> I've encountered an unexpected behavior in 1.0RC.  I first encountered
> it in one of my own forms, but the simplest way to recreate it may be:
> 
> (1) Load the writers.xml example from the 1.0RC distribution, or from
> 
>    http://www.agencexml.com/xsltforms/writers.xml
> 
> (2) Click Show Books and Hide Books a few times.
> 
> (3) Click Profiler.
> 
> This ought in normal operation to produce a profile showing the profiler
> information we have all come to love.  What it produces instead, at the 
> moment, is a Javascript error message saying 
> 
>  XSLTForms Exception
>  --------------------------
> 
>  Error dispatching event 'xforms-model-construct' :
> 
>  xforms-link-exception


I think I have now identified the source of this error.

Adding calls to Xsltforms_browser.debugConsole.write
at various locations makes clear that the error is arising in the
Xsltforms_globals.profiling_data() function, specifically in the loop

	for (var expr in XsltForms_xpath.expressions) {
			if (XsltForms_xpath.expressions.hasOwnProperty(expr)) {
				exprtab[exprtab.length] = {expr: expr, evaltime: XsltForms_xpath.expressions[expr].evaltime};
			}
	}

When I load writers.xml and click the Profiler button before having 
unloaded any author's booklist, then this loop executes eight times,
for the expressions 

  . != 'true'
  @firstname
  @lastname
  @selected
  @selected != 'true'
  @selected = 'true'
  choose(@selected != 'true', 'Show', 'Hide')
  writer

These are the XPath expressions occurring in writers.xml.

When I load the subform, by clicking Show Books, and then click Profiler, 
the loop executes eleven times:  eight times for the XPath expressions shown
above, and three more times for

  @title
  @year
  book

These are the XPath expressions in books.xml, the subform.

When I then unload the subform by clicking Hide Books, and click Profiler
a third time, I get an error message in the Profiler window, and the debugging
trace in the main-form window shows the loop being entered nine times; it
looks a lot as if the error were being raised when the loop tries to evaluate
XsltForms_xpath.expressions['@title'].evaltime.  

A little further examination suggests that after the subform is
unloaded, XsltForms_xpath.expressions['@title'] is null, so 
the attempt to get its 'evaltime' property produces an error, 
which causes the load of the profiler to fail.  

Changing the conditional in lines 302-304 of xsltforms.js (in 1.0RC) to

  if (XsltForms_xpath.expressions.hasOwnProperty(expr) && XsltForms_xpath.expressions[expr]) {
     exprtab[exprtab.length] = {expr: expr, evaltime: XsltForms_xpath.expressions[expr].evaltime};
  }

seems to allow the Profiler to launch normally even after the subform is
unloaded.  

Michael

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] conflict between subforms and the profiler?

[Alain C. <ala...@ag...>]

Hello Michael,

Thank you for this fix. I will have to check whether this is due to a 
missing treatment for XPath expression objects when unloading a subform 
because there might be some memory leak.

-Alain

Le 30/06/2012 04:36, C. M. Sperberg-McQueen a écrit :
> On Jun 26, 2012, at 7:38 PM, C. M. Sperberg-McQueen wrote:
>
>> I've encountered an unexpected behavior in 1.0RC.  I first encountered
>> it in one of my own forms, but the simplest way to recreate it may be:
>>
>> (1) Load the writers.xml example from the 1.0RC distribution, or from
>>
>>     http://www.agencexml.com/xsltforms/writers.xml
>>
>> (2) Click Show Books and Hide Books a few times.
>>
>> (3) Click Profiler.
>>
>> This ought in normal operation to produce a profile showing the profiler
>> information we have all come to love.  What it produces instead, at the
>> moment, is a Javascript error message saying
>>
>>   XSLTForms Exception
>>   --------------------------
>>
>>   Error dispatching event 'xforms-model-construct' :
>>
>>   xforms-link-exception
>
> I think I have now identified the source of this error.
>
> Adding calls to Xsltforms_browser.debugConsole.write
> at various locations makes clear that the error is arising in the
> Xsltforms_globals.profiling_data() function, specifically in the loop
>
> 	for (var expr in XsltForms_xpath.expressions) {
> 			if (XsltForms_xpath.expressions.hasOwnProperty(expr)) {
> 				exprtab[exprtab.length] = {expr: expr, evaltime: XsltForms_xpath.expressions[expr].evaltime};
> 			}
> 	}
>
> When I load writers.xml and click the Profiler button before having
> unloaded any author's booklist, then this loop executes eight times,
> for the expressions
>
>    . != 'true'
>    @firstname
>    @lastname
>    @selected
>    @selected != 'true'
>    @selected = 'true'
>    choose(@selected != 'true', 'Show', 'Hide')
>    writer
>
> These are the XPath expressions occurring in writers.xml.
>
> When I load the subform, by clicking Show Books, and then click Profiler,
> the loop executes eleven times:  eight times for the XPath expressions shown
> above, and three more times for
>
>    @title
>    @year
>    book
>
> These are the XPath expressions in books.xml, the subform.
>
> When I then unload the subform by clicking Hide Books, and click Profiler
> a third time, I get an error message in the Profiler window, and the debugging
> trace in the main-form window shows the loop being entered nine times; it
> looks a lot as if the error were being raised when the loop tries to evaluate
> XsltForms_xpath.expressions['@title'].evaltime.
>
> A little further examination suggests that after the subform is
> unloaded, XsltForms_xpath.expressions['@title'] is null, so
> the attempt to get its 'evaltime' property produces an error,
> which causes the load of the profiler to fail.
>
> Changing the conditional in lines 302-304 of xsltforms.js (in 1.0RC) to
>
>    if (XsltForms_xpath.expressions.hasOwnProperty(expr) && XsltForms_xpath.expressions[expr]) {
>       exprtab[exprtab.length] = {expr: expr, evaltime: XsltForms_xpath.expressions[expr].evaltime};
>    }
>
> seems to allow the Profiler to launch normally even after the subform is
> unloaded.
>
> Michael
>

Re: [Xsltforms-support] conflict between subforms and the profiler?

[C. M. Sperberg-M. <cm...@bl...>]

On Jun 26, 2012, at 7:38 PM, C. M. Sperberg-McQueen wrote:
> 
> ... as far as I can tell, moving from Beta3 to 1.0RC has reduced load time
> for some documents I am working with by 25 to 30%, and reduced time
> for processing some parts of the documents by 15 or 20%, and changing
> to subforms reduces the load time by another 25%.  So the new version
> of the form I'll be able to make available to my users is about twice as 
> fast, on long documents, as the current version.

Concretely, for Beta 3 vs 1.0RC using subforms, the numbers for the 
four documents I have used for testing are:

  (Size, load time, time for some simple manipulations)
  471297 bytes,  11407 vs 4111 ms, 6791 vs 3488 ms
  173970 bytes,  5123 vs 2380 ms, 7537 vs 4317 ms
  454914 bytes, 10181 vs 3161 ms, 1115 vs 2006 ms
  324214 bytes, 9810 vs 3703 ms, 6869 vs 4219 ms

I haven't yet found a good way of automating the timings, so these
are based on going through the test script just once for each document.

But they are enough to show that subforms are a huge improvement,
and that 1.0RC is a big improvement by itself.

Thank you, Alain!

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] conflict between subforms and the profiler?

[Alain C. <ala...@ag...>]

Thank you for those numbers, improving performance is the most important 
point for XSLTForms and XForms and I am convinced that the compiler 
approach is still the most pertinent one.

Actually, there is currently no optimization in XSLTForms concerning 
what the form is effectively doing: each control/element/XPath 
expression is considered independently and there are plenty of useless 
instructions and loops.

Comparing execution durations in browsers is not always pertinent 
because of internal threads for garbage collection and so on... But 
1.0RC is clearly faster :-)

-Alain

Le 30/06/2012 05:39, C. M. Sperberg-McQueen a écrit :
> On Jun 26, 2012, at 7:38 PM, C. M. Sperberg-McQueen wrote:
>> ... as far as I can tell, moving from Beta3 to 1.0RC has reduced load time
>> for some documents I am working with by 25 to 30%, and reduced time
>> for processing some parts of the documents by 15 or 20%, and changing
>> to subforms reduces the load time by another 25%.  So the new version
>> of the form I'll be able to make available to my users is about twice as
>> fast, on long documents, as the current version.
> Concretely, for Beta 3 vs 1.0RC using subforms, the numbers for the
> four documents I have used for testing are:
>
>    (Size, load time, time for some simple manipulations)
>    471297 bytes,  11407 vs 4111 ms, 6791 vs 3488 ms
>    173970 bytes,  5123 vs 2380 ms, 7537 vs 4317 ms
>    454914 bytes, 10181 vs 3161 ms, 1115 vs 2006 ms
>    324214 bytes, 9810 vs 3703 ms, 6869 vs 4219 ms
>
> I haven't yet found a good way of automating the timings, so these
> are based on going through the test script just once for each document.
>
> But they are enough to show that subforms are a huge improvement,
> and that 1.0RC is a big improvement by itself.
>
> Thank you, Alain!
>