Hi Ross, > This is my first real post to this list ... > > I'm looking for a little help in locating a specific confirmed 'bug' in OOo: > http://qa.openoffice.org/issues/show_bug.cgi?id=61228 > 'Large forms are very slow to open'
Welcome to this list, then, and welcome to the Bug Hunting :). Glad to head you want to embark on this! > One of the clues I have is that the entire OOo event loop appears to > stall during the open - all OOo document windows stall. Is this > typical? Does this suggest any specific areas of the code? What kind > of things are able to stop the entire OOo event loop? Well, basically everything :). OOo is not really multi-threaded, much of the code is single-threaded and synchronous. So, if a load is triggered from within the event loop, then the whole loop is blocked during the load process. This is "normal" ... > If possible, I would like some broad hints where to start looking. For performance problems in this order of magnitude, RTL timelogs are a pretty good start, so you already did the right thing in using them. You don't nee to build the complete package with timelogs, there's probably not much timelogs in there which are helpful for this particular problem. Instead, the idea would be to add RTL logs to suspicious places, find the most expensive parts, break them down with new logs, and so on. This requires repeated re-compilings, but has proven to be feasible to a certain extent. The difficult thing here is where to start with the initial logs. Let's see. In general, two possibilities jump to my mind: The mere loading could take all the time, or the creation of the document view after the document model has been loaded. The latter might sound strange, but there is at least one known performance problem in this area (the mentioned lot of list boxes, which don't apply here), so I would also suggest to check this. Reading is done in xmloff. Unfortunately, there is no large "readFormLayer" method or something like this. Instead, reading the XML document is done using some kind of state machine, where states (e.g. "currently reading the element office:forms") are represented by classes. You find all relevant classes for importing the form layer in xmloff/source/forms. The entry point is the OFormsRootImport class in xmloff/source/forms/officeforms.cxx. It is created when the "office:forms" element in a document is encountered, which marks the beginning of the form/control/model hierarchy. So, I suggest you start with this class. It might be interesting to only set two breakpoints in it's constructor and destructor, to see how long it takes between the two. If this already indicates that the performance problem is at this point, then you could try breaking it down. "CreateChildContext" is the relevant method - it creates a new class corresponding to a new XML element. This new class again has a CreateChildContext for further sub elements, and so on. If the breakpoints do not suggest that all the time is eaten during loading the form layer, then try finding a frame up the stack which encapsulates the whole document-loading. Place a timelog there, and see if it is responsible for the performance problem. If so, break it down, if not ... see below. The central point for creating the view for a document, with respect to the form layer, is FmFormView::ShowPage in svx/source/form/fmview. Place a time log here. If it proves the problem at this point, try breaking it down. If not ... Hmm, come back and ask me for further ideas :) Happy Hunting :) Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
