Hi, I have reduced the number of bindings about as much as I can reasonably expect to reduce them, removing all bindings to complex elements, to 444 bindings. The form is still somewhat slow however, about 1 second to enter 2 characters. I have also tried removing bindings to prefilled simple elements, bringing it down to 352 bindings, but I feel sort of ambivalent about that optimization. At any rate it should not be done all the time without users having a choice to turn it off. So any other possible optimizations?
The tree display showing all document bindings still shows the bindings that are no longer explicitly declared, but I guess they are implicit and this is the reason for the display in the tree? I'm thinking if there was a way to do multiple forms, via a sort of workflow system this would allow me to reduce things to a usable number of bindings. but then how to manage this, in a reasonable amount of time[should be delivering at the end of this month, and I'm on vacation now]? Cheers, Bryan Rasmussen On 4/10/07, bryan rasmussen <[EMAIL PROTECTED]> wrote:
Hi Lars, Yes that's what I figured, I've already removed the generation steps that takes the complex elements without attributes. I guess I'm at the point where this is not premature optimization anymore :) I was just wondering if it would lead to any side-effects to do this. Cheers, Bryan Rasmussen On 4/10/07, Lars Oppermann <[EMAIL PROTECTED]> wrote: > Hi Bryan, > > I'm not sure if I understand what you mean by this... > > Consider the following pseudo-form: > > <doc> > <xf:model> > <xf:instance> > <a> > <b> > <c/> > </b> > </a> > </xf:instance> > <xf:bind name="binding1" nodeset="/a/b" /> > <xf:bind name="binding2" nodeset="/a/b/c" /> > </xf:model> > <form> > <control xf:bind="binding2" /> > </form> > </doc> > > In this case, "binding1" dies not serve any useful purpose. It could be > removed from the document in order to speed up processing in > OpenOffice.org. Is this what you mean? > > Bests, > Lars > > bryan rasmussen wrote: > > Hi Lars, > > > > This is bad news. One solution on my end as a method for decreasing > > number of bindings, If I bind to a path /a/b/c will OO accept that I > > neglect the binding to /a/b? > > > > Cheers, > > Bryan Rasmussen > > > > On 4/5/07, Lars Oppermann <[EMAIL PROTECTED]> wrote: > >> Hi Bryan, > >> > >> I checked out your documents. I can confirm, that they perform painfully > >> slow in OpenOffice.org. I have analyzed what is happening in the > >> application and found, that the way updates are currently handled in the > >> xforms implementation is not fit to handle forms with a larger number of > >> bindings efficiently. > >> > >> This means, that I cannot make any useful suggestion on how you could > >> optimize your form, since the current implementation mostly depends on > >> the total number of bindings in the document. current.odt includes > >> almost 1000 binding elements. If you can reduce the number of bindings, > >> the form would not suffer so badly. > >> > >> I suggest, that you file an issue for this and attach your test > >> documents. > >> > >> Thanks you for pointing out this problem. > >> > >> Bests, > >> Lars > >> > >> bryan rasmussen wrote: > >> > oops, forgot to attach the documents > >> > > >> > On 3/30/07, bryan rasmussen <[EMAIL PROTECTED]> wrote: > >> >> Hi, the three attached documents show different Xforms in Open Office. > >> >> > >> >> The document params.odt is generated from a very small xml document > >> >> using a generic transformation I have to output Xforms in Open Office > >> >> for any well-formed non-mixed content document. > >> >> > >> >> The document Order.odt shows a large document generated with the > >> >> same transformation that has been edited in design mode (a UBL Order > >> >> in the Danish subset) > >> >> > >> >> The document current.odt shows a large document generated with a > >> >> transformation that reuses the generic transform but changes display > >> >> in some instances to make it much better. > >> >> > >> >> There is a performance problem with these documents. The first one has > >> >> no problem. The second one has a slight performance problem in > >> >> entering information into the fields but it seems to work reasonably > >> >> well. > >> >> > >> >> The final one is so painful to work with that if anyone asked me to do > >> >> it I would have to consider it an act of aggression. > >> >> > >> >> Now there are parts of this third document that are different from the > >> >> others, but of all these that I am aware of I can't think of any > >> >> reason why it should cause the whole document to be problem, I am > >> >> worried it is mainly a problem with document size (which would be a > >> >> lot worse with a document with say 50 invoice lines instead of the 10 > >> >> the current has. ) > >> >> > >> >> So I'm hoping that a many eyes effect will have others point out what > >> >> is causing the performance problem (so long as I can fix it) > >> >> > >> >> By the way I think development of solutions using Xforms in OO really > >> >> needs tools, I have developed some to make things easier for me and am > >> >> thinking that it might be nice to build some simple structure checking > >> >> tools that can point out potential performance difficulties. > >> >> > >> >> > >> >> Cheers, > >> >> Bryan Rasmussen > >> >> > >> > > >> > > >> ------------------------------------------------------------------------ > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
