Thread: [Xsltforms-support] optimization question
Brought to you by:
alain-couthures
Menu
▾
▴
xsltforms-support
|
From: C. M. Sperberg-M. <cm...@bl...> - 2011-12-08 02:42:44
|
As a sort of Christmas present to myself, I've used XForms to make a small toy: an implementation of a very simple virtual machine designed by Nicklaus Wirth to teach compiler writing. He used it as the target machine for a compiler for a small subset of Pascal called PL/0. I guess it's appropriate that I got it to work properly yesterday, on the Feast of St. Nicholas. http://blackmesatech.com/2011/12/pl0/index.xhtml In the current state of the page, the user can select from a small number of sample programs for this virtual machine, and step through them one instruction at a time. So far, so good. What puzzles me is the difference in response time between the relatively small programs for calculating squares of numbers between 1 and n, and the somewhat longer program (but still only a hundred instructions or so) for using random numbers to estimate the volume of a sphere. (N.B. I'm not talking about the very slow method used to calculate n mod m, which means the user will almost certainly not have the patience to step all the way through the program. I'm talking about the clock time between clicking the Step button and the completion of the actions.) The response time is not particularly great on the small programs, but it didn't particularly bother me as I was working with the form. But when the code document becomes larger, the response time degrades significantly. Are there good ways to see where the time is going? Are there obvious ways to make it faster? Thanks for any tips, suggestions, or thought-provoking questions. Michael Sperberg-McQueen -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2011-12-08 17:59:29
|
In case there are others who have occasional performance problems and aren't sure how to deal with them ... (This may be old hat to most readers of this list. But I was taught at an impressionable age that the first rule of optimization is "don't do it" and the second rule is "don't do it yet" -- I see that Wikipedia attributes this to Michael A. Jackson -- so I have never bothered to worry much about speed in my XForms work, since I have never had any particular problems with it. If you already know how to use the xsltforms profiler, you can stop reading now. If you don't know, and worry that it might be difficult to set up, keep going.) On Dec 7, 2011, at 7:42 PM, C. M. Sperberg-McQueen wrote: > ... > > Are there good ways to see where the time is going? Are there > obvious ways to make it faster? > > Thanks for any tips, suggestions, or thought-provoking questions. For the record: shortly after sending this, I remembered that Alain had recently responded to Jakob Fix saying > It could be interesting to test with recent SVN build (but before rev. > 512 if you need exsltforms), considering that the included profiler > tells you in details the different times that can be measured. Ah, I said. But how do I turn profiling on? Is this going to be a lot of work for me? For the benefit of others hesitant in the same way, let me say here: it's easier than you fear, and it was probably a lot of work for Alain, but it's not a lot of work for you. This is what I did: (1) point the form at .../trunk/build/xsltforms.xsl instead of at its earlier target (2) turn debugging on using <?xsltforms-options debug="yes"?> (3) reload the form and load one of the sample datasets (4) click the 'Profile' button in the 'Debug Mode' area at the top of the form (5) read the report, which shows a great deal of useful information (6) click the Step button and return to step 4, or else do nothing and return to step 3, or else quit. The information about which XPath expressions are taking the most time is particularly interesting and useful, as it shows that the XPath expressions I was most worried about are not in fact the ones taking the most time. If I had spent a lot of time reformulating the XPath expressions I was worried about, I would have wasted all that time in a perfect illustration of pointless optimization of things that don't make a difference. Long ago a wise man told me 'Never try to optimize until after you measure to find out where the time is going'. The profiler in xsltforms helps a LOT with that. Bravo, Alain!! -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2011-12-09 01:41:19
|
Just a short report, for the record, of my experience with the profiler now built into XSLTForms. Short version: the profiler is very helpful; in this case three relatively simple changes produced a five-fold speedup in the form. Long version: Looking at the profile information for the form I was worrying about, which had gotten too slow when the document it was operating on got bigger, I found that the most expensive XPath expressions were those used for numbering the cells of the stack and for numbering the instructions in the code area. I hard-coded appropriate numbers into attributes in the machine description, and I added a set of actions for adding a numbering attribute to the instructions in a program, after loading it. I then replaced each XPath expression of the form count(preceding-sibling::cell) +1 or count(preceding-sibling::i) with a reference to @n. I also removed the support for editing the program code; I'll move it to a separate form which communicates with the main form by bouncing the XML representation of the document off of a routine on the server. The first two changes (prenumbering the stack cells and autonumbering the instructions in the program) reduced the XForms Cumulative Refresh Time after loading a program and stepping through 50 cycles of machine time (i.e. clicking Step 50 times) from 94.6 seconds to 42.3 seconds, making the program about twice as fast. The third change (removing the editing functionality to a separate form) took it down to 17.7 seconds, another twofold speedup, for a five-fold speedup overall. Those who are curious can compare the timings and the subjective experience of the form by looking at the old and new versions of the form at http://blackmesatech.com/2011/12/pl0/v01.xhtml (old) http://blackmesatech.com/2011/12/pl0/index.xhtml (new) (Hmm. I notice that the XSLTforms I'm using on that server is an old version that doesn't yet have the profiler. I'll have to update soon.) -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: Leigh L K. J. <Lei...@xe...> - 2011-12-12 20:11:02
|
I tried your code with xsltforms-521 and noted you will need to change the custom XPath function code to use the XsltForms_ prefix and change capitalization, in two places. I also tried a quick test of putting readonly="true" (an XSLTForms extension, but common enough) on the instances that don't change by setvalue or form controls. In earlier versions (pre dependency) this produced a great performance improvement. The work Alain has done to take more advantage of dependency calculations might have lessened the effect, but I still think you should try it and run your profiler benchmark before and after. Leigh. _____ From: C. M. Sperberg-McQueen [mailto:cm...@bl...] Sent: Thursday, December 08, 2011 5:41 PM To: C. M. Sperberg-McQueen Cc: xsl...@li... Subject: Re: [Xsltforms-support] getting your feet wet with the profiler(was Re: optimization question) Just a short report, for the record, of my experience with the profiler now built into XSLTForms. Short version: the profiler is very helpful; in this case three relatively simple changes produced a five-fold speedup in the form. |
|
From: Jakob F. <jak...@gm...> - 2011-12-09 17:19:27
|
Thanks, Michael, for jumping in the cold water of profiling (at least that what it looks like from my perspective), this encourages me to follow suit. Best, Jakob. On Thu, Dec 8, 2011 at 18:59, C. M. Sperberg-McQueen <cm...@bl...> wrote: > In case there are others who have occasional performance problems > and aren't sure how to deal with them ... > > (This may be old hat to most readers of this list. But I was taught at > an impressionable age that the first rule of optimization is "don't do it" > and the second rule is "don't do it yet" -- I see that Wikipedia attributes > this to Michael A. Jackson -- so I have never bothered to worry much > about speed in my XForms work, since I have never had any > particular problems with it. If you already know how to use the > xsltforms profiler, you can stop reading now. If you don't know, and > worry that it might be difficult to set up, keep going.) > > On Dec 7, 2011, at 7:42 PM, C. M. Sperberg-McQueen wrote: >> ... >> >> Are there good ways to see where the time is going? Are there >> obvious ways to make it faster? >> >> Thanks for any tips, suggestions, or thought-provoking questions. > > > For the record: shortly after sending this, I remembered that Alain > had recently responded to Jakob Fix saying > >> It could be interesting to test with recent SVN build (but before rev. >> 512 if you need exsltforms), considering that the included profiler >> tells you in details the different times that can be measured. > > Ah, I said. But how do I turn profiling on? Is this going to be a lot > of work for me? > > For the benefit of others hesitant in the same way, let me say here: > it's easier than you fear, and it was probably a lot of work for Alain, > but it's not a lot of work for you. This is what I did: > > (1) point the form at .../trunk/build/xsltforms.xsl instead of at its > earlier target > > (2) turn debugging on using <?xsltforms-options debug="yes"?> > > (3) reload the form and load one of the sample datasets > > (4) click the 'Profile' button in the 'Debug Mode' area at the top > of the form > > (5) read the report, which shows a great deal of useful > information > > (6) click the Step button and return to step 4, or else > do nothing and return to step 3, or else quit. > > The information about which XPath expressions are taking the most > time is particularly interesting and useful, as it shows that the > XPath expressions I was most worried about are not in fact the > ones taking the most time. If I had spent a lot of time reformulating > the XPath expressions I was worried about, I would have wasted > all that time in a perfect illustration of pointless optimization of things > that don't make a difference. > > Long ago a wise man told me 'Never try to optimize until after > you measure to find out where the time is going'. > > The profiler in xsltforms helps a LOT with that. Bravo, Alain!! > > > > -- > **************************************************************** > * C. M. Sperberg-McQueen, Black Mesa Technologies LLC > * http://www.blackmesatech.com > * http://cmsmcq.com/mib > * http://balisage.net > **************************************************************** > > > > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Alain C. <ala...@ag...> - 2011-12-09 21:09:43
|
Wow! What an impressive Christmas gift for XML fans! You're absolutely right about the Profiler I added to XSLTForms: it's a wonderful tool to locate time-costing XPath expressions and refreshes. In the latest builds, the Profiler is even a form: this means that it can be customized by authors themselves. The profiling data is collected as an XML document and a specific processing-instruction tells XSLTForms which form to associate with. I plan to add more information in the Profiler instance (instances copies, the calling form source, ...): the Profiler will progressively become a real XForms Debugger written in XForms. About your form performance, I already suspected that counting preceding siblings would cost a lot of time: Javascript doesn't like loops (XSLTForms has to have its own XPath machine written in Javascript... I proposed a paper for XML Prague 2012 about how to write an XQuery compiler into Javascript instructions). I recently added support for the id() function and it's even much better for performance. Defining a subform is now another possibility to simplify a form. This is not yet documented but I already love it much. Don't hesitate to ask me about subforms if you're interested in. If you want to load another form in a new browser tab from an instance without server exchanges, defining an extra parameter for the load action should be simple with the processing-instruction capability I already use for the Profiler (this processing-instruction mechanism is very promising indeed, I'm currently building a small XRAP (XForms-REST-Apache-PHP) application with minimal generic PHP scripts, XML files and folders on server). XML allows us to consider programs as data. We might not be numerous to envision this (but the community is strong) and I have to confess that I'm still marveled by this. Thank you very much for your feedbacks! -Alain Le 09/12/2011 02:41, C. M. Sperberg-McQueen a écrit : > Just a short report, for the record, of my experience with the profiler > now built into XSLTForms. > > Short version: the profiler is very helpful; in this case three relatively > simple changes produced a five-fold speedup in the form. > > Long version: > > Looking at the profile information for the form I was worrying about, > which had gotten too slow when the document it was operating on got > bigger, I found that the most expensive XPath expressions were those > used for numbering the cells of the stack and for numbering the > instructions in the code area. I hard-coded appropriate numbers into > attributes in the machine description, and I added a set of actions for > adding a numbering attribute to the instructions in a program, after > loading it. I then replaced each XPath expression of the form > count(preceding-sibling::cell) +1 or count(preceding-sibling::i) with > a reference to @n. I also removed the support for editing the program > code; I'll move it to a separate form which communicates with the > main form by bouncing the XML representation of the document off > of a routine on the server. > > The first two changes (prenumbering the stack cells and autonumbering > the instructions in the program) reduced the XForms Cumulative Refresh > Time after loading a program and stepping through 50 cycles of machine > time (i.e. clicking Step 50 times) from 94.6 seconds to 42.3 seconds, > making the program about twice as fast. > > The third change (removing the editing functionality to a separate form) > took it down to 17.7 seconds, another twofold speedup, for a five-fold > speedup overall. > > Those who are curious can compare the timings and the subjective > experience of the form by looking at the old and new versions of the > form at > > http://blackmesatech.com/2011/12/pl0/v01.xhtml (old) > http://blackmesatech.com/2011/12/pl0/index.xhtml (new) > > (Hmm. I notice that the XSLTforms I'm using on that server is > an old version that doesn't yet have the profiler. I'll have to update soon.) > |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2011-12-09 22:53:21
|
On Dec 9, 2011, at 2:09 PM, Alain Couthures wrote:
> ...
>
> In the latest builds, the Profiler is even a form: this means that it can be customized by authors themselves. The profiling data is collected as an XML document and a specific processing-instruction tells XSLTForms which form to associate with.
I shall have to study this.
> I plan to add more information in the Profiler instance (instances copies, the calling form source, ...): the Profiler will progressively become a real XForms Debugger written in XForms.
>
> About your form performance, I already suspected that counting preceding siblings would cost a lot of time: Javascript doesn't like loops (XSLTForms has to have its own XPath machine written in Javascript... I proposed a paper for XML Prague 2012 about how to write an XQuery compiler into Javascript instructions). I recently added support for the id() function and it's even much better for performance.
Does id() require that the instance be an external instance, so it can have a DTD?
Or how does the id() function identify ID attributes?
> Defining a subform is now another possibility to simplify a form. This is not yet documented but I already love it much. Don't hesitate to ask me about subforms if you're interested in.
>
> If you want to load another form in a new browser tab from an instance without server exchanges, defining an extra parameter for the load action should be simple with the processing-instruction capability I already use for the Profiler (this processing-instruction mechanism is very promising indeed, I'm currently building a small XRAP (XForms-REST-Apache-PHP) application with minimal generic PHP scripts, XML files and folders on server).
>
> XML allows us to consider programs as data. We might not be numerous to envision this (but the community is strong) and I have to confess that I'm still marveled by this.
Subforms or a new browser tab may be exactly what I'm now looking for.
The profiler made me realize that my case switch to allow the user to edit the
PL/0 assembler code was exacting a high cost in number of additional nodes,
which in turn was making refreshes more expensive. So I'd like to move
the editing function to a different form, and make the 'Edit code' button (on
the simulator page) link to / load / transfer to the code editor. The code
editor should similarly have a 'Run code' button to go (back) to the simulator.
Since I don't want to allow arbitrary Web users to store arbitrary data on my
server, I don't want to save the 'code' instance on the server and then load
that XML document in the other form -- I'd like to hand the user's XML instance
back and forth from one form to another. Initially, I thought I could manage
this with a simple shell script: the 'Edit code' button submits the 'code' instance
to that shell script, and the shell script sends back a concatenation of four things:
1 an HTTP header with "Content-Type: application/xhtml+xml" and a blank line
2 the first few lines of an XHTML document, from <?xml-stylesheet ...
to <xf:instance id="code">
3 the code document submitted by the user (without the XML declaration)
4 the remainder of the XHTML document, from </xf:instance> to </html>
As far as I can tell, the script is working as I expected, but the browser is not
loading the new form in the way I had expected; instead I get a series of error
messages of the form "Unsupported mediatype '... [ entire body of the
inline document instance] ...' for instance #code", one for each inline instance,
and then one for #xf-instance-config.
I have probably failed to understand the true meaning of the submission process.
(Or rather: I have certainly never bothered to read up on all the details. XForms
has worked intuitively enough for me that I haven't had to, yet.)
So perhaps subforms and/or the additional load parameter are just what I'm
looking for. (In this case, my immediate goal is to avoid incurring the cost of
building all the editing widgets for the code instance until the user actually asks
to edit it. If that can be done without server hits, that would be idea. But if there
is a way to realize my original idea of passing a user instance from one
form to another by bouncing it off the server (like a soccer player passing the
ball to a teammate before running past a defender, and then getting the ball
right back from the teammate), it would be nice to know how to do that, too.
Thank you very much for your work on XSLTForms!
Michael
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
|
|
From: Kurt C. <kur...@gm...> - 2011-12-13 16:30:53
|
Alain, I too like the profiler, though I'm a bit distressed with the overall download time for the package - on Firefox it's long but acceptable, but on Chrome it seems to take forever to load (it times out at least once). Kurt Cagle Invited Expert, XForms Working Group, W3C Managing Editor, XMLToday.org kur...@gm... 443-837-8725 On Fri, Dec 9, 2011 at 4:09 PM, Alain Couthures < ala...@ag...> wrote: > Wow! What an impressive Christmas gift for XML fans! > > You're absolutely right about the Profiler I added to XSLTForms: it's a > wonderful tool to locate time-costing XPath expressions and refreshes. > > In the latest builds, the Profiler is even a form: this means that it > can be customized by authors themselves. The profiling data is collected > as an XML document and a specific processing-instruction tells XSLTForms > which form to associate with. > > I plan to add more information in the Profiler instance (instances > copies, the calling form source, ...): the Profiler will progressively > become a real XForms Debugger written in XForms. > > About your form performance, I already suspected that counting preceding > siblings would cost a lot of time: Javascript doesn't like loops > (XSLTForms has to have its own XPath machine written in Javascript... I > proposed a paper for XML Prague 2012 about how to write an XQuery > compiler into Javascript instructions). I recently added support for the > id() function and it's even much better for performance. > > Defining a subform is now another possibility to simplify a form. This > is not yet documented but I already love it much. Don't hesitate to ask > me about subforms if you're interested in. > > If you want to load another form in a new browser tab from an instance > without server exchanges, defining an extra parameter for the load > action should be simple with the processing-instruction capability I > already use for the Profiler (this processing-instruction mechanism is > very promising indeed, I'm currently building a small XRAP > (XForms-REST-Apache-PHP) application with minimal generic PHP scripts, > XML files and folders on server). > > XML allows us to consider programs as data. We might not be numerous to > envision this (but the community is strong) and I have to confess that > I'm still marveled by this. > > Thank you very much for your feedbacks! > > -Alain > > Le 09/12/2011 02:41, C. M. Sperberg-McQueen a écrit : > > Just a short report, for the record, of my experience with the profiler > > now built into XSLTForms. > > > > Short version: the profiler is very helpful; in this case three > relatively > > simple changes produced a five-fold speedup in the form. > > > > Long version: > > > > Looking at the profile information for the form I was worrying about, > > which had gotten too slow when the document it was operating on got > > bigger, I found that the most expensive XPath expressions were those > > used for numbering the cells of the stack and for numbering the > > instructions in the code area. I hard-coded appropriate numbers into > > attributes in the machine description, and I added a set of actions for > > adding a numbering attribute to the instructions in a program, after > > loading it. I then replaced each XPath expression of the form > > count(preceding-sibling::cell) +1 or count(preceding-sibling::i) with > > a reference to @n. I also removed the support for editing the program > > code; I'll move it to a separate form which communicates with the > > main form by bouncing the XML representation of the document off > > of a routine on the server. > > > > The first two changes (prenumbering the stack cells and autonumbering > > the instructions in the program) reduced the XForms Cumulative Refresh > > Time after loading a program and stepping through 50 cycles of machine > > time (i.e. clicking Step 50 times) from 94.6 seconds to 42.3 seconds, > > making the program about twice as fast. > > > > The third change (removing the editing functionality to a separate form) > > took it down to 17.7 seconds, another twofold speedup, for a five-fold > > speedup overall. > > > > Those who are curious can compare the timings and the subjective > > experience of the form by looking at the old and new versions of the > > form at > > > > http://blackmesatech.com/2011/12/pl0/v01.xhtml (old) > > http://blackmesatech.com/2011/12/pl0/index.xhtml (new) > > > > (Hmm. I notice that the XSLTforms I'm using on that server is > > an old version that doesn't yet have the profiler. I'll have to update > soon.) > > > > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point > of > discussion for anyone considering optimizing the pricing and packaging > model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > |
|
From: Alain C. <ala...@ag...> - 2011-12-14 20:11:38
|
Kurt, I'm not sure I understand correctly. Is it that, when clicking on the Profiler button, you have to wait a very long time especially on Chrome with which once you got an alert about a Javascript execution overload?? Thanks! -Alain Le 13/12/2011 17:30, Kurt Cagle a écrit : > Alain, > > I too like the profiler, though I'm a bit distressed with the overall > download time for the package - on Firefox it's long but acceptable, > but on Chrome it seems to take forever to load (it times out at least > once). > > Kurt Cagle > Invited Expert, XForms Working Group, W3C > Managing Editor, XMLToday.org > kur...@gm... <mailto:kur...@gm...> > 443-837-8725 > > > > > On Fri, Dec 9, 2011 at 4:09 PM, Alain Couthures > <ala...@ag... <mailto:ala...@ag...>> > wrote: > > Wow! What an impressive Christmas gift for XML fans! > > You're absolutely right about the Profiler I added to XSLTForms: > it's a > wonderful tool to locate time-costing XPath expressions and refreshes. > > In the latest builds, the Profiler is even a form: this means that it > can be customized by authors themselves. The profiling data is > collected > as an XML document and a specific processing-instruction tells > XSLTForms > which form to associate with. > > I plan to add more information in the Profiler instance (instances > copies, the calling form source, ...): the Profiler will progressively > become a real XForms Debugger written in XForms. > > About your form performance, I already suspected that counting > preceding > siblings would cost a lot of time: Javascript doesn't like loops > (XSLTForms has to have its own XPath machine written in > Javascript... I > proposed a paper for XML Prague 2012 about how to write an XQuery > compiler into Javascript instructions). I recently added support > for the > id() function and it's even much better for performance. > > Defining a subform is now another possibility to simplify a form. This > is not yet documented but I already love it much. Don't hesitate > to ask > me about subforms if you're interested in. > > If you want to load another form in a new browser tab from an instance > without server exchanges, defining an extra parameter for the load > action should be simple with the processing-instruction capability I > already use for the Profiler (this processing-instruction mechanism is > very promising indeed, I'm currently building a small XRAP > (XForms-REST-Apache-PHP) application with minimal generic PHP scripts, > XML files and folders on server). > > XML allows us to consider programs as data. We might not be > numerous to > envision this (but the community is strong) and I have to confess that > I'm still marveled by this. > > Thank you very much for your feedbacks! > > -Alain > > Le 09/12/2011 02:41, C. M. Sperberg-McQueen a écrit : > > Just a short report, for the record, of my experience with the > profiler > > now built into XSLTForms. > > > > Short version: the profiler is very helpful; in this case three > relatively > > simple changes produced a five-fold speedup in the form. > > > > Long version: > > > > Looking at the profile information for the form I was worrying > about, > > which had gotten too slow when the document it was operating on got > > bigger, I found that the most expensive XPath expressions were those > > used for numbering the cells of the stack and for numbering the > > instructions in the code area. I hard-coded appropriate numbers > into > > attributes in the machine description, and I added a set of > actions for > > adding a numbering attribute to the instructions in a program, after > > loading it. I then replaced each XPath expression of the form > > count(preceding-sibling::cell) +1 or count(preceding-sibling::i) > with > > a reference to @n. I also removed the support for editing the > program > > code; I'll move it to a separate form which communicates with the > > main form by bouncing the XML representation of the document off > > of a routine on the server. > > > > The first two changes (prenumbering the stack cells and > autonumbering > > the instructions in the program) reduced the XForms Cumulative > Refresh > > Time after loading a program and stepping through 50 cycles of > machine > > time (i.e. clicking Step 50 times) from 94.6 seconds to 42.3 > seconds, > > making the program about twice as fast. > > > > The third change (removing the editing functionality to a > separate form) > > took it down to 17.7 seconds, another twofold speedup, for a > five-fold > > speedup overall. > > > > Those who are curious can compare the timings and the subjective > > experience of the form by looking at the old and new versions of the > > form at > > > > http://blackmesatech.com/2011/12/pl0/v01.xhtml (old) > > http://blackmesatech.com/2011/12/pl0/index.xhtml (new) > > > > (Hmm. I notice that the XSLTforms I'm using on that server is > > an old version that doesn't yet have the profiler. I'll have to > update soon.) > > > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist > and point of > discussion for anyone considering optimizing the pricing and > packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > <mailto:Xsl...@li...> > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > |
|
From: Kurt C. <kur...@gm...> - 2011-12-14 21:16:53
|
It may be something in the form rendering - the download of the XSLT file takes very little time, but I'm looking at 15-20s before the form itself is rendered in Chrome - compared to 2-3 for the October release which I had been using. Firefox is faster, but not appreciably. This is being delivered out of MarkLogic. Kurt Cagle Invited Expert, XForms Working Group, W3C Managing Editor, XMLToday.org kur...@gm... 443-837-8725 On Wed, Dec 14, 2011 at 3:11 PM, Alain Couthures < ala...@ag...> wrote: > Kurt, > > I'm not sure I understand correctly. Is it that, when clicking on the > Profiler button, you have to wait a very long time especially on Chrome > with which once you got an alert about a Javascript execution overload?? > > Thanks! > > -Alain > > Le 13/12/2011 17:30, Kurt Cagle a écrit : > > Alain, > > I too like the profiler, though I'm a bit distressed with the overall > download time for the package - on Firefox it's long but acceptable, but on > Chrome it seems to take forever to load (it times out at least once). > > Kurt Cagle > Invited Expert, XForms Working Group, W3C > Managing Editor, XMLToday.org > kur...@gm... > 443-837-8725 > > > > > On Fri, Dec 9, 2011 at 4:09 PM, Alain Couthures < > ala...@ag...> wrote: > >> Wow! What an impressive Christmas gift for XML fans! >> >> You're absolutely right about the Profiler I added to XSLTForms: it's a >> wonderful tool to locate time-costing XPath expressions and refreshes. >> >> In the latest builds, the Profiler is even a form: this means that it >> can be customized by authors themselves. The profiling data is collected >> as an XML document and a specific processing-instruction tells XSLTForms >> which form to associate with. >> >> I plan to add more information in the Profiler instance (instances >> copies, the calling form source, ...): the Profiler will progressively >> become a real XForms Debugger written in XForms. >> >> About your form performance, I already suspected that counting preceding >> siblings would cost a lot of time: Javascript doesn't like loops >> (XSLTForms has to have its own XPath machine written in Javascript... I >> proposed a paper for XML Prague 2012 about how to write an XQuery >> compiler into Javascript instructions). I recently added support for the >> id() function and it's even much better for performance. >> >> Defining a subform is now another possibility to simplify a form. This >> is not yet documented but I already love it much. Don't hesitate to ask >> me about subforms if you're interested in. >> >> If you want to load another form in a new browser tab from an instance >> without server exchanges, defining an extra parameter for the load >> action should be simple with the processing-instruction capability I >> already use for the Profiler (this processing-instruction mechanism is >> very promising indeed, I'm currently building a small XRAP >> (XForms-REST-Apache-PHP) application with minimal generic PHP scripts, >> XML files and folders on server). >> >> XML allows us to consider programs as data. We might not be numerous to >> envision this (but the community is strong) and I have to confess that >> I'm still marveled by this. >> >> Thank you very much for your feedbacks! >> >> -Alain >> >> Le 09/12/2011 02:41, C. M. Sperberg-McQueen a écrit : >> > Just a short report, for the record, of my experience with the >> profiler >> > now built into XSLTForms. >> > >> > Short version: the profiler is very helpful; in this case three >> relatively >> > simple changes produced a five-fold speedup in the form. >> > >> > Long version: >> > >> > Looking at the profile information for the form I was worrying about, >> > which had gotten too slow when the document it was operating on got >> > bigger, I found that the most expensive XPath expressions were those >> > used for numbering the cells of the stack and for numbering the >> > instructions in the code area. I hard-coded appropriate numbers into >> > attributes in the machine description, and I added a set of actions for >> > adding a numbering attribute to the instructions in a program, after >> > loading it. I then replaced each XPath expression of the form >> > count(preceding-sibling::cell) +1 or count(preceding-sibling::i) with >> > a reference to @n. I also removed the support for editing the program >> > code; I'll move it to a separate form which communicates with the >> > main form by bouncing the XML representation of the document off >> > of a routine on the server. >> > >> > The first two changes (prenumbering the stack cells and autonumbering >> > the instructions in the program) reduced the XForms Cumulative Refresh >> > Time after loading a program and stepping through 50 cycles of machine >> > time (i.e. clicking Step 50 times) from 94.6 seconds to 42.3 seconds, >> > making the program about twice as fast. >> > >> > The third change (removing the editing functionality to a separate form) >> > took it down to 17.7 seconds, another twofold speedup, for a five-fold >> > speedup overall. >> > >> > Those who are curious can compare the timings and the subjective >> > experience of the form by looking at the old and new versions of the >> > form at >> > >> > http://blackmesatech.com/2011/12/pl0/v01.xhtml (old) >> > http://blackmesatech.com/2011/12/pl0/index.xhtml (new) >> > >> > (Hmm. I notice that the XSLTforms I'm using on that server is >> > an old version that doesn't yet have the profiler. I'll have to update >> soon.) >> > >> >> >> >> ------------------------------------------------------------------------------ >> Cloud Services Checklist: Pricing and Packaging Optimization >> This white paper is intended to serve as a reference, checklist and point >> of >> discussion for anyone considering optimizing the pricing and packaging >> model >> of a cloud services business. Read Now! >> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> _______________________________________________ >> Xsltforms-support mailing list >> Xsl...@li... >> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> > > > |
|
From: Jakob F. <jak...@gm...> - 2011-12-14 21:24:31
|
Hi Kurt, this is the exact same behaviour we have observed, and Alain suggested using the profiler to find out where the bottlenecks might be. Our forms are also served by MarkLogic, although that's a coincidence rather than the reason, of course. Jakob. On Wed, Dec 14, 2011 at 22:16, Kurt Cagle <kur...@gm...> wrote: > It may be something in the form rendering - the download of the XSLT file > takes very little time, but I'm looking at 15-20s before the form itself is > rendered in Chrome - compared to 2-3 for the October release which I had > been using. Firefox is faster, but not appreciably. This is being delivered > out of MarkLogic. > > > Kurt Cagle > Invited Expert, XForms Working Group, W3C > Managing Editor, XMLToday.org > kur...@gm... > 443-837-8725 > > > > > On Wed, Dec 14, 2011 at 3:11 PM, Alain Couthures > <ala...@ag...> wrote: >> >> Kurt, >> >> I'm not sure I understand correctly. Is it that, when clicking on the >> Profiler button, you have to wait a very long time especially on Chrome with >> which once you got an alert about a Javascript execution overload?? >> >> Thanks! >> >> -Alain >> >> Le 13/12/2011 17:30, Kurt Cagle a écrit : >> >> Alain, >> >> I too like the profiler, though I'm a bit distressed with the overall >> download time for the package - on Firefox it's long but acceptable, but on >> Chrome it seems to take forever to load (it times out at least once). >> >> Kurt Cagle >> Invited Expert, XForms Working Group, W3C >> Managing Editor, XMLToday.org >> kur...@gm... >> 443-837-8725 >> >> >> >> >> On Fri, Dec 9, 2011 at 4:09 PM, Alain Couthures >> <ala...@ag...> wrote: >>> >>> Wow! What an impressive Christmas gift for XML fans! >>> >>> You're absolutely right about the Profiler I added to XSLTForms: it's a >>> wonderful tool to locate time-costing XPath expressions and refreshes. >>> >>> In the latest builds, the Profiler is even a form: this means that it >>> can be customized by authors themselves. The profiling data is collected >>> as an XML document and a specific processing-instruction tells XSLTForms >>> which form to associate with. >>> >>> I plan to add more information in the Profiler instance (instances >>> copies, the calling form source, ...): the Profiler will progressively >>> become a real XForms Debugger written in XForms. >>> >>> About your form performance, I already suspected that counting preceding >>> siblings would cost a lot of time: Javascript doesn't like loops >>> (XSLTForms has to have its own XPath machine written in Javascript... I >>> proposed a paper for XML Prague 2012 about how to write an XQuery >>> compiler into Javascript instructions). I recently added support for the >>> id() function and it's even much better for performance. >>> >>> Defining a subform is now another possibility to simplify a form. This >>> is not yet documented but I already love it much. Don't hesitate to ask >>> me about subforms if you're interested in. >>> >>> If you want to load another form in a new browser tab from an instance >>> without server exchanges, defining an extra parameter for the load >>> action should be simple with the processing-instruction capability I >>> already use for the Profiler (this processing-instruction mechanism is >>> very promising indeed, I'm currently building a small XRAP >>> (XForms-REST-Apache-PHP) application with minimal generic PHP scripts, >>> XML files and folders on server). >>> >>> XML allows us to consider programs as data. We might not be numerous to >>> envision this (but the community is strong) and I have to confess that >>> I'm still marveled by this. >>> >>> Thank you very much for your feedbacks! >>> >>> -Alain >>> >>> Le 09/12/2011 02:41, C. M. Sperberg-McQueen a écrit : >>> > Just a short report, for the record, of my experience with the profiler >>> > now built into XSLTForms. >>> > >>> > Short version: the profiler is very helpful; in this case three >>> > relatively >>> > simple changes produced a five-fold speedup in the form. >>> > >>> > Long version: >>> > >>> > Looking at the profile information for the form I was worrying about, >>> > which had gotten too slow when the document it was operating on got >>> > bigger, I found that the most expensive XPath expressions were those >>> > used for numbering the cells of the stack and for numbering the >>> > instructions in the code area. I hard-coded appropriate numbers into >>> > attributes in the machine description, and I added a set of actions for >>> > adding a numbering attribute to the instructions in a program, after >>> > loading it. I then replaced each XPath expression of the form >>> > count(preceding-sibling::cell) +1 or count(preceding-sibling::i) with >>> > a reference to @n. I also removed the support for editing the program >>> > code; I'll move it to a separate form which communicates with the >>> > main form by bouncing the XML representation of the document off >>> > of a routine on the server. >>> > >>> > The first two changes (prenumbering the stack cells and autonumbering >>> > the instructions in the program) reduced the XForms Cumulative Refresh >>> > Time after loading a program and stepping through 50 cycles of machine >>> > time (i.e. clicking Step 50 times) from 94.6 seconds to 42.3 seconds, >>> > making the program about twice as fast. >>> > >>> > The third change (removing the editing functionality to a separate >>> > form) >>> > took it down to 17.7 seconds, another twofold speedup, for a five-fold >>> > speedup overall. >>> > >>> > Those who are curious can compare the timings and the subjective >>> > experience of the form by looking at the old and new versions of the >>> > form at >>> > >>> > http://blackmesatech.com/2011/12/pl0/v01.xhtml (old) >>> > http://blackmesatech.com/2011/12/pl0/index.xhtml (new) >>> > >>> > (Hmm. I notice that the XSLTforms I'm using on that server is >>> > an old version that doesn't yet have the profiler. I'll have to update >>> > soon.) >>> > >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Cloud Services Checklist: Pricing and Packaging Optimization >>> This white paper is intended to serve as a reference, checklist and point >>> of >>> discussion for anyone considering optimizing the pricing and packaging >>> model >>> of a cloud services business. Read Now! >>> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >>> _______________________________________________ >>> Xsltforms-support mailing list >>> Xsl...@li... >>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> >> >> > > > ------------------------------------------------------------------------------ > Cloud Computing - Latest Buzzword or a Glimpse of the Future? > This paper surveys cloud computing today: What are the benefits? > Why are businesses embracing it? What are its payoffs and pitfalls? > http://www.accelacomm.com/jaw/sdnl/114/51425149/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X