Difference between revisions of "Performance/Meetings/2009 02"
From Apache OpenOffice Wiki
< Performance | Meetings
(added section for 2009/02/27, later to be edited seperately from whole source) |
|||
| Line 1: | Line 1: | ||
| + | = 2009/02/27 = | ||
| + | |||
| + | |||
= 2009/02/20 = | = 2009/02/20 = | ||
Revision as of 02:57, 4 March 2009
Contents
2009/02/27
2009/02/20
| <LiHeng> | All: Let's start our discussion with all works and CWSes about STARTUP | |
| <sb_> | My status: | |
| <sb_> | - Set up dedicated machine with Debian unstable to run (cold start) performance tests. (Rationale for unstable is to use an environment that is not already obsolete by the time the work resulting from the measurements is finally done.) This took longer than expected (as usual). | |
| <sb_> | - Output of strace -T gives time spent in each syscall. With a little script, I combine syscalls by files/filedescriptors they work on, so get a rough overview of how much time is spent on specific files. Hot scorer is the images.zip, obviously due to many small read syscalls on it (instead of one large one). | |
| <sb_> | - Another angle of attack is to use callgrind to get estimations of cycles spent. Hopefully, the strace and callgrind data together can give meaningfull insights into where we spend time (either due to waiting on external events in syscalls or burning CPU internally). Expecting to have insights next Friday. (Carsten is doing similar things on Windows, will be interesting to see where we... | |
| <sb_> | ...agree/differ.) | |
| <sb_> | - Systematically removed unnecessary library dependencies on CWS sb107 (lib A linking against lib B, even though A does not use symbols from B). Unfortunately had zero effect on startup time (but cleaned up the code a little). | |
| kuangliang (n=aaaa@218.249.75.106) has joined #oooperformance | ||
| <cd_oo> | I am still working on measuring library loading on Windows, old times were influenced by a background av real-time scanner. Measuring the impact of loading data files like xcu, xcs, res, dat and zip files. | |
| mhu (n=matthias@nat/sun/x-ce8e3cf6b0c3a4cb) has joined #oooperformance | ||
| <yugq> | All: I list some work in http://wiki.services.openoffice.org/wiki/Performance_Project_Action_List | |
| <mhu> | Hi all, sorry for being late ... | |
| <Malte> | I am still working on todo list, Wiki updates, how-tos and playing with VTune... | |
| <LiHeng> | mhu: | |
| <cd_oo> | I am also try to consolidate a list of symbols used in the libraries which are loaded on startup. This should help us to find code that can be moved to other libraries. | |
| <LiHeng> | mhu:Good morning | |
| <mhu> | LiHeng: Good afternoon :-) | |
| <arwe> | I am working on impressperf01,checking using callgrind, valgrind, kcachegrind and VerySleepy. Also added infos to the Wiki. | |
| zhangyuwei (n=zhangyw@218.249.75.106) has joined #oooperformance | ||
| <arwe> | Mainly Load/Save on Impress (DrawingLayer Model) | |
| <arwe> | I could already identify some bottolenecks which look promising... | |
| <xiuzhi> | I am working on CWS asyncloadingimpress . | |
| <LiHeng> | xiuzhi: We talk about performance of STARTUP only , today ;) | |
| <xiuzhi> | sorry | |
| <arwe> | OOps, Okay :-) | |
| <mhu> | I am working on module store (types.rdb , ...), currently cws mhu17; startup performance (cold and warm); also: discussions with Carsten. | |
| <odf-mib> | LiHeng: Concentrating on Startup today is okay for me, but shouldn't we at least have a very short round table for load and save, too? | |
| <LiHeng> | odf-mib:If we have time it is must :), STARTUP first , and other hotspots ;) | |
| JackieSun (n=Jackiesu@218.249.75.106) has joined #oooperformance | ||
| <LiHeng> | ALL, Lots of works on STARTUP now, ... | |
| <liangjun> | mhu:I'm concerning module store, can I discussions with you? | |
| <mhu> | liangjun: yes, of course; we can do that via email, okay ? | |
| <liangjun> | mhu::) ok. | |
| <skotti> | LiHeng: Can you create a list of currently open and planned CWS for startup performance in Wiki? | |
| <LiHeng> | We focus on several points like loading libraries, module store, configmgr and so on, but we need talk about them together ... | |
| <LiHeng> | and make sure which works will be interactive | |
| <mhu> | LiHeng: can you explain, what you mean with "interactive", please ? | |
| <LiHeng> | Okay, ... | |
| <mhu> | ...maybe, which will "interact with eachother" ? | |
| <LiHeng> | Yes, Our works are not independent, influence each other | |
| <mhu> | yes, they interact, mostly in an "addition" sense; that is, they add up positively to reduce I/O wait and thus cold startup time | |
| <mhu> | ...at least... | |
| <sb_> | LiHeng,mhu: I (and I think Carsten too) are still more or less in data gathering phase, so where we will interact with other works will only later become apparent when we decide where to go based on the gathered data. | |
| <mhu> | but yes, we need to coordinate, so that we know how things interact really; Thanks Stefan, I wanted to say something similar :-) | |
| <cd_oo> | Exactly, we need data to decide where it makes sense to work on first. | |
| <mhu> | it is only that I started with mhu17 a long time ago | |
| <LiHeng> | maybe, about all works for one hotspots,we need coordinate a set of methods for measuring user experience. | |
| <mhu> | yes | |
| <LiHeng> | mhu: I think we can add all works test in our performance diagram ... | |
| <mhu> | I think, Carsten's investigations to better understand startup process will help much here | |
| <mhu> | LiHeng: yes | |
| <LiHeng> | and to compare all CWSes on the diagram | |
| <LiHeng> | So after this meeting we can talk about measuring method for STARTUP with mail list. | |
| <LiHeng> | And, we can build a uniform viewpoints on the discussions | |
| <LiHeng> | odf-mib: I think we can talk about works of load/save, now , :) | |
| <mhu> | yes, let's continue | |
| <odf-mib> | I'm currently working in improving the RTL_LOGFILE mechanism of OOo: | |
| <LiHeng> | odf-mib:Me too | |
| <odf-mib> | 1. I'm adding macros at appropriate places so that the the measured data can be assigned to the file to which it belongs. | |
| <xiuzhi> | zhangyuwei and I are working on loading large odp files | |
| <odf-mib> | 2. I'm working on a tool that creates a spreadsheet for the analysis of the data. | |
| <odf-mib> | liheng: What do you mean by "me too"? Are you are working on RTL_LOGFILE as well? | |
| <Malte> | I like the tool for the spread sheet :) | |
| <Malte> | In the pasted I created them manually from the log data... | |
| <odf-mib> | A first rough description what I do is in the Wiki: | |
| <odf-mib> | http://wiki.services.openoffice.org/wiki/RTLLogFileAnalysis | |
| <odf-mib> | When the tools is ready I will describe it in detail. | |
| <JackieSun> | I am working on improving the display & slideshow performance of high-resolution image | |
| <zhangyuwei> | My test result about asynchronism loading: | |
| <zhangyuwei> | load a document with 500pages , about 4000 objects. | |
| <zhangyuwei> | startup take about 3 seconds, parsing take about 20 seconds. | |
| <zhangyuwei> | Phase document take more time. | |
| <zhangyuwei> | If we adopt the asynchronous load, we can see the first page of a large document in 4 seconds. | |
| <zhangyuwei> | So should we take more time on asynchronous load? | |
| <LiHeng> | odf-mib:It's important message for me, I do same work on a set of new function and analysis tools for performance daigram.:) | |
| <os_ooo> | I'm working on improving the SfxItemPropertyMap/~Set/~SetInfo in svtools which is used in almost all implementations of XPropertySet/XPropertyState in all applications. | |
| <LiHeng> | odf-mib: sorry, performance diagram | |
| <os_ooo> | Writer is working already. But I have no data yet. | |
| <odf-mib> | os_ooo: You may use my new tool. I think I will have something read mid next week. | |
| <Malte> | zhangyuwei: Since I doubt we will make loading large documents lightning fast, loading in the background will make sense | |
| <LiHeng> | odf-mib:I make a dynamical analysis tools for fetching data and analyzing them with raw data, and these tools can be running on the Website | |
| <Malte> | Should be done in a way that it's only done asynchronously on file open or double click | |
| <Malte> | Not when using API, of course | |
| <odf-mib> | LiHeng: Is some information about the tool already available in the Wiki? | |
| <mhu> | Malte: why this differentiation ? | |
| <Malte> | mhu: | |
| <LiHeng> | odf-mib:Next week, I will post them | |
| <xiuzhi> | Malte: we test it on two cases | |
| <Malte> | a) An API call should only return when loading is done, IMHOI | |
| <Malte> | b) It will make loading documents a little bit slower | |
| <mhu> | Malte: let's discuss that offline / elsewhere ... | |
| <Malte> | the mailing list is the best place for that discussion, I think... | |
| <LiHeng> | odf-mib:For format limitation, I want post with new performance trace server ,at first ,but I can get the machine this month, so I change to post it on wiki first :) | |
| <zhangyuwei> | Malte: It take some amount time on file open or double click | |
| <LiHeng> | odf-mib:So I want to get your suggestions about analysis of performance data | |
| <zhangyuwei> | Malte:sorry, It take same amount of time on file open or double click | |
| <Malte> | No need to correct small typos ;) | |
| <odf-mib> | liheng: First thoughts are in the Wiki. I plan to provide more details next week. | |
| <LiHeng> | odf-mib:We can discuss some details via mail | |
| <odf-mib> | liheng: okay | |
| <LiHeng> | That's all |
2009/02/13
| <mhu> | LiHeng: Hi; yes lets start the discussion | |
| <frankl> | yugq: O.K. now I see the mail. Had too many mails these days due to new OOo user survey preparance. | |
| <yugq> | frankl, it doesn't matter! | |
| |<-- | liangjunzeng has left freenode ("Leaving.") | |
| liangjun (n=zenglj_@218.249.75.106) has joined #oooperformance | ||
| <LiHeng> | As odf-mib say, we need to create a list in the WIKI, and display our works about performance | |
| zhangyuwei (n=zhangyw@218.249.75.106) has joined #oooperformance | ||
| <erAck> | a list of performance CWSs with short (!) description is certainly good, but I'm not a friend of duplicating information that is available by just a click on a linkt to EIS. | |
| <skotti> | Thorsten Bosbach (TBO) recently published the results and some background information at http://wiki.services.openoffice.org/wiki/Performance/Startup/Linux | |
| <mhu> | Maybe, in EIS you dont see what is done why and other interesting topics that can better be explained in a wiki ? | |
| <Malte> | I would prefer to have most of the info in Wiki, not all details in EIS... | |
| <LiHeng> | erAck:The list is not only for CWSs and some jobs must to do, that can help us to coordinate our work, to prevent some counteraction of works | |
| <skotti> | EIS for CWS/Issue tracking, Wiki for everything else | |
| <Malte> | +1 :) | |
| <arwe> | It's always possibe to add links to OOO issues to the wiki entreis where needed, to link to the technical descriptions | |
| <erAck> | additional information in the wiki is fine, just copying info from EIS such as CWS members IMHO isn't necessary. | |
| <arwe> | So, the Wiki should contain overview and concept informations | |
| <mhu> | erAck: yes, duplication is not necessary, I guess | |
| <LiHeng> | erAck:Sure! | |
| <_Nesshof_1> | i would like to see for the single efforts some information like the owner of the effort, next action items, external dependencies | |
| <_Nesshof_1> | and how to get more detailed information like documentation, data, EIS data and so on | |
| <_Nesshof_1> | in the moment it's almost impossible to see and research within 5 minutes what the status of the performance efforts are | |
| <skotti> | +1 | |
| <odf-mib> | I think we should start with something simple. If that does not work, we may extend this later. | |
| <odf-mib> | So, why not just start with a list of the CWSs, the owners of the CWSs, and short description. | |
| <LiHeng> | odf-mib: +1, We would create a list that detail the mainly action of a improving jobs and expectation of that work | |
| <skotti> | I would prefer a different approach | |
| <odf-mib> | For items where we do not have a CWS so far, we may at least add the owner and a description. | |
| <skotti> | define goals -> assign people (make groups) -> assign CWS to groups# | |
| <skotti> | Each group to work on *one* CWS with *one* goal at a time | |
| <LiHeng> | odf-mib:The simple list can be created, and every item also can be a entry of exposition .. | |
| <LiHeng> | odf-mib: We can start with simple list | |
| <LiHeng> | :) | |
| <Malte> | In the past I used this for coordination: | |
| <Malte> | http://tools.openoffice.org/performance/performance-activities-overview.html | |
| <Malte> | Of course internally I had a column with assigned people. | |
| <Malte> | Nowadays we could have such data on a public list too | |
| <LiHeng> | Malte: Thank you | |
| * mhu | also thinks that we should keep it simple as possible, but no simpler: an item in the should explain what is done, and what we expect it will improve. | |
| <LiHeng> | +1 | |
| <odf-mib> | Malte: +1, if we add the CWS names and owners | |
| <Malte> | I will clean up the list | |
| <Malte> | Before that, I will also talk to different people involved to check status | |
| <Malte> | One question: HTML or Wiki? | |
| <Malte> | Wiki is a nightmare with tables :( | |
| <yugq> | put on wiki should be better, the list is clearer than EIS | |
| <LiHeng> | Wiki I think | |
| <Malte> | If the initial table is in a good state, maintaining it in Wiki might be OK... | |
| <Malte> | I will do that next week | |
| <arwe> | Wiki is much easier to work with, You need no editing software | |
| <odf-mib> | Malte: What do you mean by "clean up"? Do you want to keep the content of the list? | |
| <Malte> | all content that is still valid - yes of course | |
| <mhu> | Malte: how about Weblog Publisher to maintain the table in the wiki ? | |
| <yugq> | Malte, use Sun-Wiki-Publisher extension of OOo | |
| <LiHeng> | We can arrage the final table in HTML in project page and link to WIKI Page | |
| <Malte> | Weblog Publisher for Wiki? | |
| <mhu> | yugq: :-) | |
| <Malte> | Will give it a try... | |
| <Malte> | I guess with that list we start with a good overview of what's going on. | |
| <Malte> | What about config mgr discussion now? | |
| <_Nesshof_1> | Malte: I find your list quite impressive, but it's not clear to me, what our main priorities should be ? | |
| <LiHeng> | Malte: Yuguoqiang can maintain works in RedFlag first in WIKI, and mail to you, we discuss about the init version | |
| <Malte> | We will give the items some different priorities | |
| <Malte> | They will come from UX and other... | |
| <skotti> | _Nesshof_1: This is one of the reasons why i'm not happy with Malte's approach | |
| <odf-mib> | Malte: As for load/save, we probably need to make a new analysis before we can know whether any item on the list is still a reasonable action. | |
| <Malte> | odf-mib: yes, that's why I said "clean-up" | |
| <Malte> | skotti: ? | |
| <odf-mib> | skotti: We must differ between a list like Malte's, and its content. | |
| <_Nesshof_1> | I also would like to see which items deliver in what performance goals, e.g. startup performance, load/save | |
| xiuzhi (n=xiuzhich@218.249.75.106) has joined #oooperformance | ||
| <odf-mib> | The structure of the list is okay for me, but I would start with a fresh content. | |
| <skotti> | odf-mib: Maybe, i'll see how it looks and comment on it then | |
| <Malte> | _Nesshof_1: That's obvious... (and already on the list) | |
| <_Nesshof_1> | Malte: for some of the items this is obvoius, for other not | |
| <Malte> | The first version doesn't have to be "done in stone" | |
| <Malte> | Let's simpy start, and discuss afterwards | |
| <_Nesshof_1> | what are our priorities e.g. rendering compared to starup ? | |
| <skotti> | odf-mib, Malte: My primary concern is to minimize the entry barrier for my brain and other people: If you have a group working on one item, it should be fairly easy to join in. But - depending on the list you proposed it can work as well | |
| <Malte> | my: startup. | |
| <Malte> | But as I saif: UX will come up with priorities | |
| <LiHeng> | Malte: Only need add team members:) | |
| <Malte> | yes :) | |
| <Malte> | My internal list has it | |
| <Malte> | need to include redoffice now | |
| <mhu> | Martin: Malte's list is historic and serves on as a starting point. This new project starts new, and concentrates first on startup and doc load/save. | |
| <LiHeng> | Malte:Okay, Yuguoqiang will send some detail to you | |
| <Malte> | Great, thanks! :) | |
| <erAck> | my suggestion is: 2-3 people work on startup, create reproducible measurements, workout approaches such as combining libraries and factoring out code that is not needed during startup, and try them in a CWS. | |
| <mhu> | I think, configmgr alone justifies the work of 2-3 people... | |
| <LiHeng> | erAck: For easily to benchmark, we can create to try them to several CWS | |
| <cd_oo> | This sounds like a very good approach to me. Exactly what I am trying to do. | |
| <_Nesshof_1> | erAck: after the measurment phase we should have to identify the most important area for improvement, dettermine the efforts and come than to a list, what we want to start with | |
| <erAck> | _Nesshof_1: of course. | |
| <LiHeng> | So we can go next, to list some works and ideas for STARTUP | |
| <cd_oo> | I think we need a solid analysis for the startup process before we should think about ideas. Ideas must be based on pure data and from my point of view we have not enough data. | |
| <erAck> | I'm also quite sure that during startup code is called for fucntionality that isn't needed for startup. This needs evaluation in callgrind/kcachegrind or similar. | |
| <skotti> | cd_oo: +1000 | |
| <_Nesshof_1> | cd_oo: you already take care of this ? | |
| <mhu> | yes, I think Carsten (cd_oo) is right. | |
| <LiHeng> | We do some about Configmgr and integration of libraries in Beijing | |
| <erAck> | btw, has anyone tried APPR in the last years? | |
| <skotti> | APPR? | |
| <erAck> | http://wiki.services.openoffice.org/wiki/APPR | |
| <yugq> | I think it will be worth to do that merging dynamic library which provide UNO services. | |
| <LiHeng> | cd_oo: very agreed | |
| <cd_oo> | Yes, I try to make a solid analysis to provide as much data as possible. This must be the base for a discussion what to do next. | |
| <_Nesshof_1> | what aspects do you try to analyse beside loading time of libs ? | |
| <_Nesshof_1> | also unused code ? | |
| <_Nesshof_1> | what else do we need to look at for an analysis ? | |
| <cd_oo> | Currently I am focusing on file I/O during startup (cold and warm start) which include loading time of libs and data files. | |
| <skotti> | cd_oo: Do unnecessary string conversions (8 bit -> unicode) have any considerable performance impact? | |
| <LiHeng> | cd_oo:We need data from different conditions and trace/analysis in order to create appropriate benchmark | |
| <skotti> | And we need data for all platforms to ensure we do not introduce regressions to the other platforms when improving one... | |
| <frankl> | I want to add something to the valid “we need data” request from cd_oo. | |
| <frankl> | The OOo Renaissance team (http://wiki.services.openoffice.org/wiki/Renaissance) is currently working on a new OOo User Survey. | |
| <cd_oo> | We need to look at the code/data which is processed during startup. I would like to see a list of classes and data we use. Then we can look into details why something happens. That's another big problem, nobody knows why we do certain things during startup. | |
| <frankl> | This new survey is about what our users do with the OOo and how satisfied they are working with the software. This new survey also has a part about performance. We want to know how our users feel about OOo's current performance against the overall performance of their system. Furthermore we want to know on what computer systems (PC, Notebook, Netbook, etc.) do our users use OOo most of their time. | |
| <frankl> | Please have a look at the final draft of the survey here: | |
| <frankl> | http://surveys.services.openoffice.org/surveys/index.php?sid=69531&lang=en | |
| <frankl> | We plan to go live with this survey by next week. I hope to have first result within 2-3 weeks. | |
| <erAck> | frankl: I don't think we'll need a survey to tell us that users aren't satisfied with performance ;-) Use of systems may be interesting data. | |
| <cd_oo> | On my test platform, a 3 year old notebook, OpenOffice.org needs about 35 seconds to start a Writer (cold start). | |
| <skotti> | frankl: Is there a way to retrieve information about performance from the usage tracking stuff? | |
| <frankl> | erAck: How do you want to know what our users really bothers? | |
| <_Nesshof_1> | erAck: but it can tell what we should focus on | |
| <_Nesshof_1> | especially if we look on file import export | |
| <_Nesshof_1> | what do our users think wehre we need the most improvement | |
| <arwe> | erAck: Users can show performance problems we are not even aware of (and which may be low hanging fruits, too) | |
| <skotti> | Probably just: Which functionality is used most | |
| <frankl> | and we can see changes in performance rating from version to version. | |
| <erAck> | frankl: we do have 3 points we hear/read everywhere: startup,load,save | |
| <LiHeng> | cd_oo: mayde longer :( | |
| <arwe> | frankl: We also have complaints about OOo blocking during AutoSafe. There may be more like that, too. | |
| <skotti> | erAck: But we need to know about how much e.g. the mail-merge wizard is used. It's ridiculously slow. But if nobody uses it... or maybe that's the reason why nobody uses it .... | |
| <mhu> | arwe: yes, and that is "doc save", which is already on the list | |
| <odf-mib> | arwe: This is like save. If we are fast enough there, then this is not an issue any longer:-) | |
| <xiuzhi> | frankl: the svrvey looks very good. I will ask more Chinese end-user to join it. | |
| <skotti> | Do we care for export formats? Binary filters can be annoying as well. | |
| <frankl> | erAck:I have not asked that because I am not sure that our users know wat AutoSave is. | |
| <arwe> | odf-mib: A general solution here (prob. with multithreading) will be superior, independent from times (will we make such fast progesses...?) | |
| <frankl> | xiuzhi: Maybe we have the opportunity to translate it to Chinese? The tooling does support it. | |
| <xiuzhi> | frank: agree. | |
| <LiHeng> | ALL: Time up, today, some details we can discuss them in mailing list :) | |
| <frankl> | xiuzhi: Do you have resources to do that? Please send me an email I will create an account. | |
| <skotti> | Can we get a list of action items and due dates? | |
| <LiHeng> | frankl: I have resoucr to do :) | |
| <frankl> | :-) Good news! | |
| <xiuzhi> | frankl: the guys from zh_CN team can do that | |
| <xiuzhi> | LiHeng: right? | |
| <LiHeng> | xiuzhi: you mean chenglin's people? | |
| <--| | yugq has left #oooperformance | |
| <xiuzhi> | LiHeng:yes | |
| <frankl> | Please forward them my email address: frank.loehmann@sun.com | |
| <LiHeng> | frankl: Okay! | |
| <xiuzhi> | LiHeng: what do you think about my idea? | |
| <mhu> | okay, bye for today; have a nice weekend... | |
| <LiHeng> | xiuzhi: sure! And I can provide some others, I think |
2009/02/06
#oooperformance
| [INFO] | Channel view for “#oooperformance” opened. | |
| YOU (odf-mib) have joined #oooperformance | ||
| <xiuzhi> | liheng: Happy Niu Year | |
| <odf-mib> | Hello everyone! | |
| <frankloe> | Hi, all! | |
| <os_ooo> | Hi all! | |
| arwe (n=chatzill@c141103.adsl.hansenet.de) has joined #oooperformance | ||
| <skotti> | Hi all | |
| Dieter_ (n=chatzill@192.18.8.1) has joined #oooperformance | ||
| <Dieter_> | Hi all :-) | |
| <Dieter_> | Malte can't attend our IRC today | |
| <liheng> | xiuzhi:Happy Niu Year, ;) | |
| <liheng> | Hi,ALL | |
| <liheng> | we all here, other people can't back in office | |
| <liheng> | Dieter_:can we start? | |
| <Dieter_> | yes, please | |
| <arwe> | Hi all and thanks. Willsomeone moderate or will we all throw in what we want | |
| <skotti> | We have no agenda, afaik | |
| <skotti> | so it's more like throwing in i guess | |
| <Dieter_> | liheng is project owner and will moderate this IRC | |
| <liheng> | Dieter_:Some new persons in our meet, do you think we need a interduce ? | |
| <Dieter_> | yes, let's start with a brief introduction | |
| * skotti | : QA Engineer, Sun. Responsible for Automated testing of the framework component with current focus on test script performance | |
| _Nesshof_1 (n=_Nesshof@nat/sun/x-b56788764e68ee9c) has joined #oooperformance | ||
| mhu (n=matthias@192.18.8.1) has joined #oooperformance | ||
| <mhu> | Hi all, sorry for being late (traffice jam :-) ) | |
| <liheng> | skotti:welcome :) | |
| <arwe> | Developer, responsible for DrawingLayer, working inter-applicationwide (always incompatible from svx...) | |
| * skotti | : I intend to do the performance measurements here at Sun | |
| <xiuzhi> | skotti:welcome | |
| <skotti> | xiuzhi: Thank you | |
| <os_ooo> | Hi, I'm Oliver Specht (os), working in the Writer team for ages and I'm now working especially on load/save performance issues. | |
| <xiuzhi> | os_ooo: Hi ,glad to see you here | |
| <liheng> | I'm LiHeng, from RedFlag 2000, worked on RedOffice(Based OOo) for 8 year, and also responsible for interoperability of RedOffice. | |
| * skotti | : My OOo nick is 'jsk' and my real name is Joerg Skottke but please call me Skotti | |
| <liheng> | os_ooo:Welcome :) | |
| <stephan_> | And I'm Stephan Bergmann (sb), working on startup performance (after working on other parts of OOo for years :) | |
| JackieSun (n=Jackiesu@218.249.75.106) has joined #oooperformance | ||
| <Dieter_> | _Nesshof_1: Hi Martin, would you like to join the project? | |
| <_Nesshof_1> | Dieter_: I would like to offer my support as Program Manager, if wanted | |
| <liheng> | ALL:First I list some status of performance works in our side ... | |
| <xiuzhi> | _Nesshof_1: :) | |
| <Dieter_> | _Nesshof_1: yes, that's a good idea | |
| <liheng> | _Nesshof_1:Thank you, Martin. | |
| <liheng> | 1.Refactoring Configmgr: Clear some superfluous objects for improving speed of startup. And it can reduce 2's in current version of RedOffice ... | |
| <liheng> | 2.To collect test cases for measure OOo's performance | |
| <liheng> | 3.And to design and implement some specail tools for measuring of OOo performance | |
| <liheng> | Last:To compare performance value between OOo and the other offices. | |
| <liheng> | These are mainly works we do in RedOffice | |
| <liheng> | And we are analyzing performance of Load/Save of ODF. | |
| <frankloe> | Good! Are these results already visible at the OOo wiki? | |
| <frankloe> | I am asking because the new project home page is now online: http://performance.openoffice.org | |
| <liheng> | Some of Refactoring Configmgr is on wiki page | |
| <liheng> | frankloe:Yes, I saw it, Thank you very mach. | |
| <stephan_> | To work on startup performance, I am currently breaking down overall startup into its parts, to see where time is going. Concentrating on Linux for now, using a combination of callgrind and strace to better estimate true wall clock time. Will start to put my findings into the wiki beginning of next week. | |
| <skotti> | So i gather our first focus is on startup performance? | |
| <mhu> | stephan_: Carsten Driesner is following a similar approach (on Windows, though); maybe, you could coordinate your work / findings ? | |
| <stephan_> | skotti: No, I think we work on different parts in parallel (startup, appl. load/save). | |
| <stephan_> | mhu: Yes, thanks for pointing it out. I will contact him. | |
| <mhu> | okay, thanks. | |
| <skotti> | I would then suggest that we bring some overhead into play from the start ;-) | |
| <mhu> | skotti: "overhead" ? | |
| <liheng> | stephan_:We make some benchmark code for measuring startup in realtime, not in debug state. I mail them with first test report in next week. | |
| <skotti> | mhu: Yep! | |
| <stephan_> | liheng: great, thanks | |
| <stephan_> | skotti: what do you mean? | |
| <skotti> | I would like to have it documented in Wiki which parts we're working on and who is responsible | |
| <skotti> | Goal being that we can see what progress the single parts are making | |
| zhangyuwei (n=zhangyw@218.249.75.106) has joined #oooperformance | ||
| <mhu> | at least, we should document enough od our work, so that we dont loose oversight (who is doing what) | |
| <skotti> | If we have enough workforce to address several areas at the same time we might head into chaos otherwise | |
| <mhu> | skotti: I am also here to help avoid some of that chaos :-) | |
| * skotti | would have preferred a single threaded approach: One area at a time | |
| <skotti> | mhu: I know. But i have a very simple brain. ;-) | |
| <mhu> | :-) | |
| <odf-mib> | skotti: the web page and wiki are very new. We of cause plan to add documentation there. But that will take a few days. | |
| <frankloe> | If we have documented the current status of the project, we should announce the project officially to get some visibility on OOo and the press. | |
| <odf-mib> | frankloe: Yes, but let's have the documentation first. | |
| <odf-mib> | I think we are in the middle of a status check. Who's next? | |
| <skotti> | liheng: The list you posted: Which parts are planned, analysed and implemented? | |
| <frankloe> | odf-mib:Yes, the first impression always counts! | |
| <liheng> | frankloe:Yuguoqiang can help us to maintain Project page and WIKI page | |
| <zhangyuwei> | Excuse me, My name si Zhangyuwei, is a member of REDOffice2000. I'm working on loading/saving performance, and have done something about odf loading performance. | |
| <frankloe> | liheng:Sure! | |
| <xiuzhi> | zhangyuwei: you can discuss the issues with os_ooo. He focuses on load/save performance now | |
| <odf-mib> | xiuzhi: Several more people are working on load save performance, so please have any discussions on the mailing list | |
| <liheng> | frankloe:So, he will contact to you next week, and consult you :) | |
| <xiuzhi> | odf-mib: ok | |
| <mhu> | hi zhangyuwei, welcome. | |
| <liheng> | skotti:Yes,:) and create some specail tools | |
| <frankloe> | liheng:OK | |
| <liheng> | skotti: and we also make performance report for master builds | |
| <zhangyuwei> | os_ooo:I have done something about asynchronism loading file and imporved load performance. | |
| <odf-mib> | zhangyuwei: What did you do exactly? | |
| <os_ooo> | zhangyuwei: I want to make load/save process faster by changing the interfaces between xmloff and sw. | |
| <skotti> | liheng: Can i see the results of the performance reports? I've got something of that sort as well but i'm not at all happy with my approach | |
| <zhangyuwei> | I have finished asynchronism odp load | |
| <liheng> | skotti:Yes, I will publish them on project page or wiki | |
| <skotti> | liheng: Cool | |
| <mhu> | os_ooo: Oliver, similar to what SB said, could you start with improving the understanding of what exactly takes what time during loading documents ? | |
| <skotti> | liheng: I just applied for membership on the OOo performance pages, can you add me with a QA role | |
| <skotti> | ? | |
| <os_ooo> | mhu: I will add some information to the wiki. | |
| <mhu> | os_ooo: okay, thanks. | |
| <liheng> | skotti:Sure | |
| <odf-mib> | All: I think we in general must provide more information on which area we are working, and must share results as soon as possible. Otherwise its difficult to coordinate things. | |
| <odf-mib> | zhangyuwei: In which CWS is the asynchronous load/save implemented. | |
| <arwe> | Good to hear that we will get some numbers; i would like to know which documents are used for measurements. Does anybody use documents form practice? I mean e.g. bugdocs from cases where users have reported that it is too slow? | |
| <zhangyuwei> | os_ooo:But I have some pr oblem about asynchronism load. slide sorter flush is monstrosity and slowly | |
| <arwe> | When we extract numbers from documents we make up ourselves, wnat willthe numbers represent (load/save of course, not startup)..? | |
| <liheng> | ALL:Sorry, we can focus on starpup and load performance, but, we must make sure for how to measure our works | |
| <skotti> | arwe: Yes and no. We can make up documents of our selves which include a defined feature set. | |
| <xiuzhi> | odf-mib: He did not create CWS until now .I will ask him to do that ASAP | |
| <arwe> | skotti: Do we have a collection of real world user documents with load/save performance issues? | |
| <zhangyuwei> | odf-mid: base on OOO3.0dev-m9 | |
| <odf-mib> | arwe: Maybe we can have this discussion on the list? | |
| <skotti> | arwe: Yes, i think we have quite a repository. I'm taking this as action item for me: Find documents suited for performance measurement with bias towards real live scenarios | |
| <arwe> | skotti: Would it make sense to have a set of 'problematic' documents accessible over the Wiki-Page? | |
| <skotti> | arwe: I think so. | |
| <arwe> | skotti: If they are not confidential, please put them on the Wiki-pages. | |
| <skotti> | arwe: Yep. | |
| <liheng> | arwe:Yes we discuss it on the list, and we are collecting cases of performance now, but they are in Chinese | |
| <arwe> | Skotti: It will be interesting if the diverse measurements from diverse people will have comparable results with the same document set. | |
| <arwe> | This would be a good check if the measurements go in the correct direction... | |
| <skotti> | arwe: You won't get any dependable results unless you have a well defined test environment | |
| <skotti> | arwe: Or more correctly "comparable" | |
| <arwe> | skotti: Yes, but different measurements and methods should pont in the same direction when aplied to the same documents. | |
| <arwe> | skotti: Just a good test if the measurements give comparable results. | |
| <skotti> | arwe: Very likely | |
| <liheng> | ALL:I think we have a lot of things to do for peformance of OOo, but we can discuss them in list dev@performance.openoffice.org and select important things to disuss at IRC | |
| * mhu | thinks we could start with the idea that document load / save is generally a factor 10 too slow; then dependency on particular bugdoc documents becomes smaller ... | |
| <skotti> | liheng: +1 | |
| <arwe> | skotti: I would be skeptical if my measurements with the same docs point in a completely different direction than someone else's... | |
| <skotti> | arwe: Yup, so would i | |
| <mhu> | liheng: yes, lets discuss most of this on the new mailing list. | |
| <skotti> | arwe: But i've seen it happen. Weird scenario, utterly unexpected | |
| <liheng> | ALL: So, I will post agenda of every IRC to mailing list, please you subscrib it ;) | |
| <liheng> | Time up, today,:) thank you and welcome to new Performance Project! | |
| <mhu> | liheng, xiuzhi: most of your teams are still not back from spring festival vacation ? | |
| <xiuzhi> | mhu: all of our members will be available next Monday | |
| <liheng> | Matthias:Someone has more vacation and someone can't get ticket:( | |
| <liheng> | But they will be back next week :) | |
| <mhu> | ah, okay; understood; hope the two of had some good time, though |
