Re: [Xsltforms-support] getting your feet wet with the profiler (was Re: optimization question)
Brought to you by:
alain-couthures
Menu
▾
▴
Re: [Xsltforms-support] getting your feet wet with the profiler (was Re: optimization question)
|
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 > |
