Difference between revisions of "Performance/Meetings/2009 07"

Revision as of 06:26, 12 August 2009

Performance/Meetings/2009 07/17

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2009/07/17
Time: 14:42– 16:49
Meeting No.:

Agenda:

(15:42:54) yugq change the topic: Please update your status!
(16:02:16) arwe: Hi all :-)
(16:02:25) yugq: hi all:)
(16:03:14) yugq: Please update your status.
(16:03:14) yugq: Liheng and other guys in Beijing are taking part in some training now.
(16:03:14) yugq: liangjun's status: working on CWS configtune01 to handle the package and install problem.
(16:07:31) erAck: morning
(16:08:33) cd_oo: cd's status: Had to make fixes for MinGW port for CWS fwk112. Therefore integration into master is delayed. I want to start with optimizations next week looking to consolidate our libraries. Especially to only have code/data in startup libs that is needed on startup, other code/data should be moved out.
(16:08:37) arwe: I was working on some common performance stuff regarding rendering, especially fat lines (lines with a LineWidth) and charts where 10000th of that lines are used.
(16:09:10) ***erAck has no status update, working on oasis odf
(16:09:12) arwe: Fat lines and MetaFile recording has been optimized. Also Fat line geometry creation
(16:09:40) arwe: I will also look for chart performance regarding rendering and MetaFile stuff
(16:14:03) arwe: Especially with the new AntiAliasing it is pretty hard to get the same performance as before (which is achieved in most cases); people simply do not want to accept that AA costs time at all.

Performance/Meetings/2009 07/10

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2009/07/10
Time: 16:01– 16:56
Meeting No.:

Agenda:

(4:01:09 PM) liheng: Hi,all
(4:01:32 PM) cd_oo: hi all :-)
(4:02:38 PM) yugq: hi all
(4:03:14 PM) liheng: Good morning / afternoon! :)
(4:04:03 PM) liheng: Let's update our status.
(4:04:57 PM) liangjun: hello all.:)
(4:07:30 PM) erAck: good morning /afternoon
(4:08:31 PM) liheng: My status:Arrange check-points of performance diagram for comparing 3.0, 3.1 and 3.2 in OOoBenchmarkSystem, and build script and testcases.
(4:09:44 PM) cd_oo: My status: CWS fwk108 (Writer optimizations regarding language files) has been integrated into DEV300m52. CWS fwk112 (non-rebased libraries) has some problems with two build bot systems (Ubuntu 8.04 AMD64 and MinGW), hopefully this can be fixed today. Currently I am busy with file picker issues and Windows 7 compatibility.
(4:09:54 PM) sb: My status is that I am still busy re-implementing a (fully functional, but not yet optimized) configmgr, as explained last week.
(4:11:14 PM) Matthias: Hi all, sorry for being late
(4:11:37 PM) liheng: Matthias: We are updating our status:)
(4:11:50 PM) Matthias: ah, okay...
(4:12:45 PM) liangjun: my status : continue odf document load performance :)
(4:12:50 PM) ***Matthias is still working on mhu20, specifically implementing buffered file IO for windows; unix (linux, solaris that is) can already be tested
(4:13:40 PM) liheng: sb:Your re-implementing work is for simple and distinct configmgr?
(4:15:51 PM) sb: liheng: What do you mean with "distinct configmgr"?
(4:17:12 PM) liheng: Matthias:I think cws mhu17 is also for optimizing IO ?
(4:18:29 PM) Matthias: yes, mhu17 was optimization of 'store' (basically cold start, memory consumption, instruction count), already integrated
(4:19:07 PM) liheng: sb:I think , clear or simple configmgr, easy to re-implement on optimizing
(4:20:26 PM) sb: liheng: Yes, exactly.
(4:20:49 PM) liheng: Matthias: Yuguoqiang and me just do some benchmark on it :)
(4:21:45 PM) liheng: sb:Do you have some solution in config data format?
(4:22:01 PM) liheng: sb: Do you have some solution in config data format?
(4:22:07 PM) Matthias: liheng: fine with me; can you somehow publish the results, please ?
(4:24:35 PM) liangjun: sb: I know the package script rarely.Our testing are manual configuration data. we can discuss with mail if you have any question.
(4:24:49 PM) liheng: We are launching OOoBenchmarkSystem on http://219.239.158.91:8080/OOoBenchmarkSystem/, and when we make out some report ,we will post them in Status Trace
(4:25:57 PM) sb: liheng: For now, I read in all the xcs/xcu files at startup, and write all modifications to a single XML file (with a format based on xcu format) in the user layer. Once the functionality is stable, I will experiment how best to optimize this (potentially even using something completely different in the end).
(4:29:00 PM) sb: liangjun: What do you mean with "package script"? And what do you mean with "our testing are manual configuration data"? Can I build CWS configtune01 and give the resulting OOo installation set a try, without any other things I would need to do? (Also, I wonder why the fresh setup of CWS configtune01 is based on rather old DEV300m41, instead of something current like DEV300m51.)
(4:35:50 PM) liangjun: sb: CWS configtune01 , our source code can compile. but it can't build a install packge. now we manual replace OOo's some files , and test our current code.
(4:35:54 PM) liheng: sb:liangjun means they do some works with to change the library and config-files manaully. And configtune01 is really has some trouble in get installation set, and other engineers are working for fix these problem.
(4:36:50 PM) liangjun: liheng: thanks :P
(4:38:14 PM) sb: liangjun: I see. So, I will wait with having a look until the experience will be smoother...
(4:42:14 PM) liheng: We need to put the tools that combine configfiles into one file into makefile and make installation well.
(4:43:38 PM) liangjun: liheng: yes, but ... :)
(4:44:41 PM) liangjun: I know little.
(4:46:36 PM) liheng: I can solve those problem, in a week:)
(4:47:16 PM) liangjun: :P
(4:51:41 PM) liheng: No more questions for me ;)
(4:52:21 PM) Matthias: liheng: did I miss something important at the beginning when I was not yet here ?
(4:52:48 PM) liangjun: sb: I'm sorry. :-(
(4:53:28 PM) sb: liangjun: Nothing to be sorry about. :)
(4:53:41 PM) liangjun: :P
(4:54:25 PM) liheng: Matthias: No, only some other status, and you can find them in wiki next week :)
(4:54:51 PM) Matthias: liheng: okay, thanks.
(4:55:33 PM) liheng: Okay, see you all next week!
(4:55:51 PM) Matthias: yes, have a nice weekend, bye all
(4:56:11 PM) liheng: Nice weekend! bye all.
(4:56:22 PM) erAck: bye all
(4:56:27 PM) Matthias left the room (quit: "good bye").
(4:56:35 PM) yugq: bye all

Performance/Meetings/2009 07/03

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project

Date: 2009/07/03
Time: 15:58– 17:01
Meeting No.:

Agenda:

(3:58:38 PM) The topic for #oooperformance is: Next meeting scheduled : ... please put the right date / hour ( CEST / UTC .. and so on )
(3:59:55 PM) arwe: Hi All!
(4:00:55 PM) yugq: hi all
(4:01:01 PM) cd_oo: Hi all :-)
(4:01:10 PM) liangjun: hi all :P
(4:04:54 PM) Matthias: Hi all
(4:06:21 PM) ***Matthias wonders whether the meeting has started already ?
(4:06:34 PM) sb: Anybody interested in getting this going? Liheng yesterday wrote that he would like to "discuss refactoring goals of configmgr".
(4:06:51 PM) sb: I can step in on that:
(4:07:07 PM) Matthias: yes, please go ahead, stephan
(4:07:52 PM) sb: I (finally ;) got to writing something in the Wiki (<http://wiki.services.openoffice.org/wiki/Performance/Configuration>) about what I am currently doing and what my motivations are:
(4:10:00 PM) sb: As I explained before, I see no other solution than to re-implement configmgr, to be able to then implement performance improvements, fix long-standing bugs, etc. So, in a way my work is rather different from the RedFlag work:
(4:11:24 PM) Malte: almost missed it ;)
(4:11:51 PM) liheng: Hi,all sorry I'm late
(4:11:57 PM) ***Matthias thinks sb's wiki summary of the configmgr problem(s) clearly hints to re-implementation
(4:12:06 PM) sb: They concentrate on specific performance improvements, while I (hope to) lay the foundations to implement any such improvements in a good way. I would be happy to see good ideas (if not code) from the RedFlag work make its way into the final new configmgr. (But still haven't seen working code from RedFlag, to see exactly what their work is, to experiment with it, etc.)
(4:12:33 PM) sb: .
(4:13:05 PM) sb: Hope this clarifies the situation. What do others (esp. the involved RedFlag people) think?
(4:13:25 PM) Matthias: sb: I think RedFlag's work fits into your second point (rearrange to improve performance)
(4:13:40 PM) Matthias: (or is supposed to fit)
(4:15:04 PM) Matthias: also: what we discussed some (long) time ago, was simplyfication of the code / design together with simplification of files on disk
(4:16:03 PM) liangjun: sb: sorry , we had sent some codes on cws. and we will update this code later
(4:16:17 PM) sb: mhu: yes, sure, exactly. The only issue I see is that any diff they produce against current configmgr will not apply to new configmgr, so their work is somewhat wasted.
(4:16:46 PM) mba [n=mba@nat/sun/x-7aabbe3bad493b4b] entered the room.
(4:16:50 PM) sb: liangjun: can you give me a ping once there is code there that I should have a look at? Thank.
(4:17:11 PM) Matthias: sb: I knew what you meant :-) yes, right, you should somehow coordinate, and if you are faster ...
(4:18:04 PM) liangjun: sb: ok .
(4:18:13 PM) Matthias: ...that is why we are having these discussions, to try not to waste each others time with too much overlapping implementations ...
(4:18:36 PM) sb: My rough time estimates are to have something working (w/o any performance improvements) in about a month, then start improvements. (But those estimates are still rather vague.)
(4:18:38 PM) Matthias: ... and to agree what is important enough that we throw some people on it
(4:19:54 PM) Matthias: I think "about a month" is a perfectly valid estimate (and actually fast)
(4:19:55 PM) liangjun: I think we can send our currently code on cws, :P
(4:20:56 PM) yugq: mhu: about the configuration related api, i think the config item path is quite like some kind of XPath, is it an old fashion solution or there are other cosiderations? (and also the hierachy structure). I think simplify the api is a good idea. (4:21:05 PM) liangjun: next week . and tell you on maillist
(4:21:38 PM) Matthias: yugq: yes, see sb's third point in the wiki (and also the recent email discussion)
(4:21:59 PM) sb: liangjun: Thanks.
(4:22:34 PM) Matthias: ...so, yes, at some point in time we should probably also think about simplifying the api
(4:23:06 PM) liangjun: sb: you are welcome :)
(4:23:41 PM) sb: yugq,mhu: Yes, lets proceed in steps. Simplifying the API (and simplifying the code using the configmgr) is probably a rather huge step, but will probably eventually become necessary.
(4:23:43 PM) Malte: sb: What about meeks comments with wrt some API not / almost not needed?
(4:24:12 PM) Malte: avoid that from the beginning?
(4:24:45 PM) liangjun: mhu: sb: yes , It is very good idea
(4:24:47 PM) ***Matthias still agrees to sb's three step proposal on the above mentioned wiki page
(4:25:17 PM) sb: Malte: I am currently implementing all the interfaces, but do not flesh out the functions that are never called (startup, smoketest, those are the things I am currently testing). What never gets called will stay in that nonfunctional way for now.
(4:25:32 PM) Malte: OK :)
(4:29:19 PM) yugq: mhu, sb: yes. I think a light weight configuration framwork is needed. When we're looking into configmgr in OOo, we find the structure is so complicate. So some times i wonder the old structure if need so much complicate indeed or not. I think many problems comes from these kind of complication. But we can't find a another configuration data definition way.
(4:30:44 PM) Matthias: yugq: this is sb's first step: cleanup and simplify the code, that it can better be changed in future
(4:31:02 PM) Matthias: s/code, that/code, so that/
(4:32:05 PM) Matthias: ...including, even further simplifying it.
(4:34:03 PM) sb: yugq: I do not see that the current UNO API per se has that bad consequences on the way the configuration data can be defined/stored. The complex UNO API probably has consequences on the complexity of the current configmgr implementation, which in turn has consequences on being easily able to modify the data storage thing in the current implementation.
(4:37:29 PM) yugq: sb: Ok, maybe api changes, the implementation can be simple also. :)
(4:38:46 PM) sb: yugq: I hope to have everything simple in the end, data format, implementation, API. :)
(4:39:39 PM) yugq: My status: I'm maintained the benchmark system web site this week. It enables register user now. And the further function will be put on soon later.
(4:39:49 PM) liheng: Yes, data format is basic for the others
(4:40:14 PM) liheng: URL: http://219.239.158.91:8080/OOoBenchmarkSystem/ , We add user register so that you can save you benchmark rawdata and results of analysis for multi-version and comparison in the futher
(4:40:16 PM) yugq: sb: yes, perfect goal!
(4:40:32 PM) yugq: liangjun: data is basic, format, i think not.
(4:40:51 PM) yugq: liheng:data is basic, format, i think not.:)
(4:42:29 PM) liheng: I means to make data format as simple as possible is basic for simplify implement and API it's not?
(4:45:22 PM) yugq: liheng: yes, i think so. I misunderstood you :P.
(4:45:34 PM) sb: liheng: Remember, a simple implementation is not and end in itself. What counts is that we ultimately improve performance, most probably via better data file format/usage. The final implementation should then be as simple as possible given the constraints imposed by the performance requirements.
(4:46:15 PM) sb: ...but I think we all mean the same thing, just express it differently. ;)
(4:46:54 PM) liheng: sb: Yes, ;)
(4:46:56 PM) ***Matthias thinks so too ... many different words for almost the same thing :-)
(4:47:10 PM) yugq: :-D
(4:48:45 PM) liheng: In our early works we only combining all data in one file
(4:51:19 PM) sb: liheng: And maybe that already can give enough of a performance boost? All shared data in one file, all per-user data in another, merging just those two at runtime?
(4:51:49 PM) Matthias: that was the idea, at least
(4:52:56 PM) yugq: sb: no, every user has a copy, so no merging at runtime. Thus the security is a big argument.
(4:53:09 PM) liheng: the prototype benchmark result in wiki http://wiki.services.openoffice.org/wiki/Configmgr_Refactoring/test_result_2009_02_19
(4:53:42 PM) sb: yugq: Yes, so my idea is to do it slightly differently (as I just described), and see whether that gives good enough performance.
(4:55:08 PM) liheng: sb:I think it not enough performance so that we are going on :)
(4:55:53 PM) sb: liheng: I see. Lets see where we are going, then. :)
(4:56:52 PM) liheng: I think data format is first
(5:00:44 PM) liheng: Ok, time up
(5:01:00 PM) liheng: Bye and see you next week

Go back