Performance/Meetings/2009 02

From Apache OpenOffice Wiki
Jump to: navigation, search


Brief meeting summary

  • Due to the increasing number of both participants and topics at the weekly IRC meeting Peter Junge (nick: peter13j) proposed several adjustments for the proceedings:
    1. Meeting agenda should be available latest two days before the upcoming meeting starts
      • No attendee did disagree
      • for the beginning Li Heng should be in charge of the agenda
      • later someone else could take over resposibility
    2. A moderator should streamline the discussion in order to keep the agenda and avoid off-topics.
      • Everyone basically agreed
      • Li Heng is in charge for the beginning
      • later this responsibility may rotate among attendees
      • the moderator couples action items and volunteers
    3. Providing Meeting minutes (MM)
      • After discussion the item was agreed on
      • The MM should be a very brief listing of results and decision on top of the IRC log
      • Action item: peter13j to write first MM (Minute takers note: AI completed)
      • Action item: peter13j to find appropriate location on OOo Wiki for MM
      • Writing MM should revolve among regular attendees
    4. Splitting the meeting according to the subprojects
      • This item was not agreed
      • Stephan Bergmann (nick: sb_) made the counterproposal to hold the weekly IRC meeting as overall status update, without any in-depth technical discussion
      • This counterproposal found unanimous agreement
  • Load/Save
  • Action item: Malte Timmermann shall create a Project Member page on OOo Wiki
    • Minute takers note: AI completed

Log of meeting

<liheng> ALL:At first, we discuss some proposal of IRC from Peter.
odf-mib (n=chatzill@nat/sun/x-993d38e7b7e35ec9) has joined #oooperformance
<odf-mib> Hi everyone!
<peter13j> Shall I take the word?
<liheng> Yes:)
<peter13j> OK, maybe not everyone may have read mail this morning ...
<liheng> 1) The *agenda* should be available two days before the meeting.
|<-- liheng has left (Excess Flood)
<peter13j> ... I have made some proposals to adjust the IRC to the increasing number of attendees
<peter13j> 1) The *agenda* should be available two days before the meeting.
<peter13j> Requests for agenda items should be posted on the list. For the start Li
<peter13j> Heng should be responsible for the agenda. As this task does not have to
<peter13j> be necessarily done by the project lead, we might find a volunteer to
<peter13j> get in charge later.
<peter13j> Is this agreeable?
liheng (n=temp@ has joined #oooperformance
<Malte> yes :)
<cd_oo> yes
<sb_> yes
<odf-mib> yes
<yugq> yes
<xiuzhi> +1
<liheng> yes!
<liangjun> yes
<zhangyuwei> yes
<ycheng1> yes
FrankL ( has joined #oooperformance
<odf-mib> peter: Maybe you just ask if someone disagrees. This may be faster.
<peter13j> 2) A *moderator* should streamline the discussion in order to keep the
<peter13j> agenda and avoid off-topics. For today Li Heng should be taking care,
<peter13j> for the future this can alternate, maybe it's a good idea to have 3 or 4
<peter13j> people to rotate. The moderator can also assign action items during the
<peter13j> discussion.
<Malte> But not so much Fun ;)
<peter13j> Any Disagreement on item 2?
<Malte> 3... 2... 1....
<Malte> All agreed :)
<liheng> OK:)
<peter13j> 3) I would also like to suggest to write *meeting minutes* (OOo wiki?).
<peter13j> As we also log the IRC it can be very brief just listing results,
<peter13j> decisions and action items. Writing meeting minutes should revolve among
<peter13j> regular attendees.
<peter13j> Disagreement?
<os_ooo> Why would anybody need minutes additionally?
<peter13j> Just for an brief overview of results for those who was not able to attend.
<sb_> if we keep the meeting *short and to the point* (next item), I would guess the log is sufficient
<erAck> peter13j: I disagree to "The moderator can also assign action items". The mod probably doesn't know my scheduling ...
<peter13j> erAck: Should be done by finding vlounteers, not by force
<erAck> peter13j: sounds better :)
|<-- Malte has left (Remote closed the connection)
<peter13j> ... maybe by forcing someone into the volunteer role ;-)
<cd_oo> yes
<liheng> erAck:Action item mean some simple task like - Writing meeting minutes or Talk to manager about assigning more project resources
<peter13j> *meeting minutes* seems not to be clear yet, voting?
Malte (n=Malte@nat/sun/x-f2be14a9af43d05a) has joined #oooperformance
<liheng> peter13j:I think everyone will agree if meeting minutes like a simple list for targets and results
<erAck> I guess the log is ufficient, just summarize _results_ of the discussion on top, such as "agreed on ..."
<peter13j> erAck: This is also my intention
<liheng> +1
<JackieSun> +1
<cd_oo> +1
<os_ooo> +1
<sb_> +1
<liangjun>  :)+1
<tora-japan> +1
<JackieSun> but who is the vlounteer?
* peter13j volunteers for this MM to give an example
<peter13j> 4) *Splitting the meeting*. As we already have several subprojects, such
<peter13j> as load/save and startup performance, not anyone has to join every
<peter13j> meeting. The IRC meeting can either be split into several topical
<peter13j> meetings on different days or the weekly meeting topic can change round
<peter13j> robin, with some flexibility depending on priorities and progress.
<peter13j> This is the last proposal, disagreement?
<liheng> I think we can splitting our works and targets into several subproject like tuning/refactoring/tooling ...
<erAck> peter13j: yes, I disagree. I don't see the need for splitting the meeting.
<odf-mib> No, but we may where possible divide the agenda into a first part that is of interest for all, and a 2nd one that is about a particular sub project
<peter13j> Which model is preferable?
<sb_> I would think it is better to have this IRC meeting as a quick overall status meeting (everyone joining in), and leave anything more detailed to mail/ad-hoc IRC sessions, etc.
<peter13j> sb_: good point
* erAck seconds sb_
<Malte> I agree with sb_
<cd_oo> Good idea
<liheng> sb_:I agree
<peter13j> OK, that's all for me, back to liheng as mod
<liheng> except we need reach a consensus for some point.
<peter13j> Haven't we? (More or less)
<Malte> We missed some clarification on where to store the minutes/results
<liheng> Okay return to agenda...
<Malte> I would out them in front of the IRC log
<liheng> WIKI
<peter13j> Malte: OOo Wiki
<Malte> Sure Wiki
<Malte> But where.
<Malte> I wouldn't put them away from the log
<liheng> Like you say, front of IRC log
<liheng>  :)
<peter13j> I write the MM and take finding a place as AI ...
<peter13j> ... we can discuss my solution next time if necessary
<erAck> .../Performance/meeting_minutes and from there link to individual .../Performance/meeting_minutes/2009-02-27 files.
* peter13j seconds erAck
<Malte> I don't
<Malte> Extra files for intended to be very small minutes?
<erAck> Malte: including the log
<liheng> we can simply to put MM in front of IRC log
<Malte> Which then also need to link to the correct log?
<Malte> liheng: yes
<Malte> peter13j: Here you find the links to current logs:
<liheng> Anybody can read the MM, and watch detail in log if you want
<Malte> Since you volunteered to do it today ;)
<peter13j> Malte: Thanks :-)
<erAck> other possibility: write the overview in .../Meetings and log in .../Meetings/yyyy-mm-dd
<liheng> erAck:Okay,
<Malte> Seems erAck didn't look in yet.
<Malte> But peter13j will find the right place there.
<liheng> but, mouthly enough
<Malte> No need to discuss further, IMHO
* erAck confesses he didn't
<liheng> Okay, return to topics
<liheng> Lots of discussion of configure data requirements, about admin shared data
<liheng> We need to reach a consensus for these requirements about configuration
JackieSu1 (n=Jackiesu@ has joined #oooperformance
<liheng> In currently implement we also support to change configuration by admin
<Malte> With current, you mean implementation used in OOo, not what you currently are working on, right?
<liheng> No! I mean our works.:)
<yugq> I think the read-only data is most argued.
<Malte> So you now have multi layers again?
<liheng> So we think it have only one problem, that is everyone can change share data in binary cache file manually
<liheng> Malte: We make tools for processing logical multi layer
<sb_> liheng: that's no problem, I would say (it is true with the current OOo implementation as well)
<Malte> liheng: That's not clear enough to me for further discussions.
<Malte> If you don't have multiple layers, I can't imagine how it could work
<liangjun> Malte: yes , We have two layers : One is default data and the other is user data.
<Malte> liangjun: Thanks for clarification :)
<liangjun> Only we merger the two layers into one file.:P
<yugq> Malte, our implementation just like a cache doing, and it can be updated when the share registry is modified.
<liheng> sb_:OOo can disable cache file, but our implementation must have it
<Malte> liangjun: Then it's _not_ clear to me anymore.
<sb_> liheng: oh, I see (had forgotten that)
<Malte> please let's avoiding cache files for now, since the other stuff is more critical
<Malte> I meant: avoid the discussion...
<Malte> liangjun: Please explain how configuration and merging works now in your implementation
<Malte> I can't imagine how 1 file could be sufficient for our requirenments
<liheng> Malte:Okay,Yuguoqiang is creating CWS and put all source, we can discuss them later:)
<Malte> makes sense :)
|<-- JackieSun has left freenode (Read error: 110 (Connection timed out))
<liangjun> Malte: ok , we will writer our implementation in wiki,and explain that.
<Malte> liangjun: Thanks :)
<liangjun> Malte::P
<liheng> As we want to create a list of targets of performance ...
<liheng> we discuss some ideas  of  Loading like
<liheng>         *Asynchronous Loading
<liheng>         *Analysis of load
<yugq> I published some ideas on loading in wiki page:
<liheng> Some other ideas we want to try?
<ycheng1> I'm tring to merge asynchronous loading work of Symphony(based on oo1.1) into OO3.1 code base, but there are so many changes, it need more time ...
<tora-japan> Buffered I/O ... sequential file reading, writing.
<tora-japan> Memory mapped file I/O ... for resource manager, handling, *.res
<odf-mib> liheng: We must not forget Saving.
<liheng> odf-mib:Yes :)
<zhangyuwei> About  <font size="3">asynchronous loading, I have done something about the asynchronous load. Mainly about odp loading. I'm fixing bugs.</font>
<liheng> odf-mib:We list them next IRC :)
<ycheng1> yuwei, great work:)
<xiuzhi> ycheng1: zhangyuwei has two crash to fix. He will finish it next week. Maybe you can cooperate with zhangyuwei
<Malte> ycheng1: "I'm tring to merge asynchronous loading work of Symphony" - you are from IBM?
<odf-mib> Is the asynchronous load already in a CWS?
<ycheng1> Yes, it's me
<ycheng1> I'm ChengYuan, from Symphony performance team of IBM
<liheng> odf-mib:It's a CWS from xiuzhi
<xiuzhi> not finish the CWS until now. next week
<zhangyuwei> <font size="3">ycheng1:hello,chengyuan</font>
<Malte> ycheng1: Great. So you are allowed to commit your changes to the OOo source repository now?
<ycheng1> Yes, we have the plan and I'm doing the work, but it may need longer time
<Malte> ycheng1: Sounds promising :)
<ycheng1>  :-D
<odf-mib> Great!
<Malte> Since we have people from different compaies, and individuals here now:
<Malte> Should we list the nicks with some description somewhere?
<ycheng1> agree
<Malte> I will prepare a Wiki page for that
<Malte> peter13j: Write me an AI ;)
<peter13j> OK
<erAck> Malte: we already have that:
<liheng> We insert our information in that
<Malte> I would like to have a list with performance people only.
<tora-japan> I would like to propose some idea at the level of UNIX system calls.
<tora-japan> How to efficiently utilize them to enhance I/O performance, ...
<tora-japan> Does anyone also have experiences and interestings in it?
<Malte> There could be a comment about what they do for performance
<Malte> tora-japan: interest: yes: experience: no ;)
<liheng> Malte:We already have a CWS list
<tora-japan>  :)
<Malte> I can't use the CWS list to match nick names.
<sb_> tora-japan: see my work at
<liheng> I forget that, sure,we need that
<cd_oo> tora-japan: I am currently looking at I/O performance under Windows. We should try to find optimizations that fit for all systems.
<tora-japan> Good!
<cd_oo> tora-japan: See my work at:
<liheng> Malte:We can collect the information in mailing list and make a page on WIKI
<tora-japan> sb_: That's nice.
<Malte> liheng: I prepare the Wiki with information I know, then people can update
<liheng> ALL:Time up :(


<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, 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@ 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
<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@ 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@ 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> 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> 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


<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_@ 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@ 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
<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> 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@ 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?
<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 ( 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> 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, 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:
<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



[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 ( has joined #oooperformance
<skotti> Hi all
Dieter_ (n=chatzill@ 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@ 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@ 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:
<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@ 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 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
Personal tools