Difference between revisions of "Speed Up Load"
(performance load) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
The “load” operation can be divide into 3 parts from the performance point of view, parse XML files, load media resources, create related window and refresh. Each part performance is influenced by different factors. | The “load” operation can be divide into 3 parts from the performance point of view, parse XML files, load media resources, create related window and refresh. Each part performance is influenced by different factors. | ||
| Line 65: | Line 64: | ||
[mailto:yuguoqiang@redoffice.com?subject=load performance yuguoqiang@redoffice.com] | [mailto:yuguoqiang@redoffice.com?subject=load performance yuguoqiang@redoffice.com] | ||
| + | |||
| + | [[Category:Performance]] | ||
Latest revision as of 11:40, 26 February 2009
The “load” operation can be divide into 3 parts from the performance point of view, parse XML files, load media resources, create related window and refresh. Each part performance is influenced by different factors.
Contents
XML Parse
There is a contrast on different XML parsers: http://wiki.services.openoffice.org/wiki/XML_Load. From the result we can see some evaluate chance by switching the OOo document XML parser(SAX parser based on expat) to libxml2 SAX parser.
XML Parser
- In condition of large amount of XML files, the tiny parse time win on one file can be accumulated and amplified.
- For large XML files, the libxml2 SAX parser can get a time win by a high rate by comparison with OOo SAX parser.
- It's theoretical easy to switch OOo SAX parser to libxml2 SAX parser, just need change the UNO wrapper.
Inner Document Structure
Generally, parsing “content.xml” costs most time, take example of swriter, the parse time is not liner increased by the XML file size. So the problem lies on building inner document structure. There may be some core arithmetic inefficient, or the structure is natural inefficient(?).
Media Resource
When loading large size media resources such as pictures, it is synchronized now. Though there is a so called asynchronous implementation, that actually is delay loading. This causes UI blocks a long time.
Another problem is the resource reloaded repeatedly some times, as I see after document saved and after some edit operation. Maybe this is not the problem about load, it is a some kind issue.
We can add multi-thread to handle media resources. The media resource is loaded only when asked. First draw some occupation when the resource is asked, and then create some threads to load the resource and later fill into the occupation. This will enable UI response quickly and not blocked anymore.
Window Creation and Drawing
After document parsed, many windows are created, such as menu bar, tool bar, editor, and perhaps a property window. Current OOo window mechanism is single threaded in one mainframe. That is the mainframe is shown only if all of child windows are ready to show.
First, let's classify the windows and think about how it is loaded and its relatives.
| |
|
|
| Menu bar | Many configuration layer merged, get the icon, and create the bar dynamically. | Share and user layer configuration.
Document. |
| Tool bar | Similar with menu bar. | Similar with menu bar. |
| Status bar | Similar with menu bar. Need information from document detail. During document loading, it is overlapped by the progress bar. | Similar with menu bar.
Document. |
| Editor | Absolutely after document content parsed. | Document. |
| Property dialog | If there is some special element like table and list item at default cursor position, property dialog generally need create and show. | Document. |
The menu bar, tool bar and status bar are created dynamically according to different configuration layers. From parsing different configuration XMLs and merging layer to creating the window and inserting items, it is not a high speed action. These windows are relatively static after they are modified by user and their configuration file is not conflicted with document content. So these loading these windows can happened parallel with document parsing and loading to editor. Or we can cache the menu bar, tool bar and status bar by modules, loading the cache is quite more efficient than before.
