Performance/Meetings/2008 07
|
|
|---|
|
Quick Navigation Team Communication Activities |
| About this template |
Performance/Meetings/2008/07/31
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000 and the Community ??
Performance Project
Date: 2008/07/31
Time: 15:38– 17:12
Meeting No.:
Agenda:
(15:58:35) liheng: hi xiuzhi
(15:59:11) xiuzhi: liheng:hi afternoon
(16:00:16) xiuzhi: I suggested that we can have bi-weekly meeting if we have no more issues to discuss.
(16:02:01) liheng: xiuzhi:OK, i am agree :)
(16:03:04) mhu: Hi all
(16:03:08) xiuzhi: liheng::)
(16:03:22) xiuzhi: mhu: moin
(16:03:24) liheng: hi: matthias
(16:03:28) liangjun: mhu: hi:)
(16:03:34) kuangliang: hi,mhu
(16:03:44) mhu: moin :-)
(16:05:20) yugq: hi
(16:05:20) liheng: mhu:xiuzhi suggested that we can have bi-weekly meeting in the future , what is your opinion?
(16:05:21) mhu: Okay, I have read the agenda; you have a new team member? will he join our meeting also?
(16:06:19) liheng: Guo yongshi, jion this meeting next time, today, he have another meeting of our company
(16:06:19) liheng: :)
(16:06:20) mhu: liheng: I think, having a meeting every two weeks only is fine when we are all busy working.
(16:07:25) mhu: (also: I will be out on vacation for the next two weeks; so next meeting would be in 3 weeks)
(16:07:51) liheng: I can have a meeting every week, yugq , kuangliang, liangjun also, but xiuzhi maybe so busy :)
(16:08:23) xiuzhi: liheng: not true. I means if we have not too many issues to discuss
(16:08:36) mhu: When we still have so much to discuss, as we did in the past, I think it is okay to have a meeting every week.
(16:09:00) xiuzhi: liheng: weekly meeting is ok for me
(16:09:09) mhu: xiuzhi: yes, that is what I also mean.
(16:09:53) liheng: Okay, we keep weekly meeting
(16:10:43) liheng: xiuzhi: Okay, and the proposal of paper "Improving and Maintaining Performance of OO in Long-term Development" has been passed selection,
(16:11:14) xiuzhi: xiuzhi: great
(16:11:29) xiuzhi: liheng: great
(16:11:36) mhu: yes, I think that is great also
(16:11:54) xiuzhi: liheng: and OO -> OOo
(16:12:00) liheng: we need more discussion for tools and analysis of performance of OOo
(16:12:05) liheng: Yes, OOo:)
(16:12:27) liheng: Peter has mentioned to me:)
(16:13:59) mhu: okay, discusssion of benchmarking tools... do have any ideas?
(16:14:13) mhu: s/do have/do you have/
(16:15:00) liheng: mhu:In your opinion, what are urgent improvement of Tuning and Benchmark tools?
(16:16:33) mhu: well, I think we once discussed that first of all we need a set of "standard and reproduceable" measurements / tests.
(16:17:15) mhu: ...say: how long it takes to load (and display?) a particular reference document.
(16:18:30) mhu: ...this would be the macroscopic / user relevant measurement.
(16:18:50) liheng: Yes, for a long time most raw-data will be comparability and explicit
(16:20:07) liheng: please explain "how long it takes to load (and display?) a particular reference document." :(
(16:20:29) mhu: what I am thinking about is something like: Y=f(x1, x2, ...,xN); where Y is the user visible / macroscopic value, and the x's are the variables that cause it
(16:20:58) mhu: liheng: okay, I will explain...
(16:22:31) mhu: I said: "...set of reproduceable measurements"; one measurement out of that set of measurements could be a measurement of the time it takes to load one of the (yet to be defined) reference documents.
(16:22:42) mhu: does this make it clearer?
(16:24:10) liheng: you mean the individual measurements in specified parts?
(16:24:36) liheng: for load a reference documents?
(16:25:01) mhu: not yet, measurements of specified parts may be measurements of those x1, ...,xN's
(16:25:46) mhu: in this example, I meant a simple number, say: 5 seconds
(16:25:51) yugq: mhu: about Y=f(x1, x2, ...,xN), may I understand that like: Y=speed, x1=startup speed, x2=load/save document speed, x3=menu shown speed ... ?
(16:25:59) liheng: If we have enough manpower we can not only define the f(x1.......xN) but also paint a big picture for key paths and hotspots
(16:27:48) mhu: yugq: well, almost; Y would the total load time, say 5 seconds, and x1 may be xml parsing speed, x2 memory allocation speed, x3 locking speed, and so on; f() would basically tell how these factors contribute to the end result Y.
(16:28:09) mhu: liheng: yes, that is the direction that I am thinking :-)
(16:30:23) liheng: after them, we must define effectual and comparability benchmarks for all node (x1.....xN)
(16:30:28) liheng: right?
(16:31:37) mhu: yes, probably; but hopefully not for so many, but only the most important ones; that is, for those that contribute to many Y's (like xml parsing, memory alloc, ...).
(16:34:18) liheng: For a long time, I think for create a set of tools to automatically analyze data of benchmark and compare them between several versions
(16:35:12) liheng: mhu:Network seems slowly:(
(16:35:31) mhu: so, yugq already mentioned: startup speed, load/save speed, menu open speed; that would be the different macroscopically observable Y's in my world; they may all depend on different x's, but may also depend on a set of same x's.
(16:36:18) mhu: liheng: I can wait, dont worry too much about your network
(16:37:26) liheng: mhu:For a long time, I think of create a set of tools to automatically analyze data of benchmark and compare them between several versions
(16:37:35) mhu: ...that set of same x's (contributing to many Y's) would be the ones that I would create individual benchmarks for, to start with.
(16:38:07) mhu: oh yes, I forgot to answer that one, stay tuned...
(16:38:25) mhu: ..set of tools to automatically analyse...
(16:39:35) mhu: ...I think of that can be done with a "T-Test" called statistical method (testing statistically difference between two datasets), do you mean someting like this?
(16:41:37) mhu: sorry for all this math; I have had a course in "six sigma methodology", and in my previous life I have been a physicist :-)
(16:41:44) liheng: Yes, most of, and all data can be traced in difference versions
(16:42:02) mhu: yes
(16:44:14) liheng: Yes, now we need a start point to try which tools can do that
(16:44:14) liheng: :)
(16:45:24) mhu: well, tooling would be two parts: one part to collect the data (maybe that is what you have from Malte?), the other part to analyze it.
(16:46:02) liheng: Three parts in my mind, testcase, benchmarks, method of report
(16:46:52) mhu: if you can produce a set of measurements, say: measure a documents load time 10 times in a row, for 2 versions of OOo, than I can provide you with the code to do a T-Test of that datasets.
(16:47:58) mhu: yes, you right; but at this high level, I think report can initially be "the diff is 5% and it is statistically significant" or so.
(16:48:17) liheng: i am not clear of "than I can provide you with the code to do a T-Test of that datasets."
(16:48:20) liheng: :)
(16:48:52) mhu: I have written a small set of Java methods some years ago; I can give you the code.
(16:49:27) mhu: meaning you dont need to invent the math yourself
(16:50:05) liheng: oh, yes thank you,
(16:50:22) mhu: you are welcome
(16:50:46) liheng: i have a mistake for 'code' and 'datasets'
(16:50:47) liheng: :)
(16:51:37) mhu: TTest.java = code, {5,4,4,5,...7,5} = dataset
(16:51:42) mhu: :-) :-)
(16:52:39) liheng: i mean the report must can lead more developers to notice some problem of performance
(16:53:51) liheng: one target is tuning for every version ,and another is refactoring in the future.
(16:54:01) mhu: well, yes. on the other hand, the numbers of course must be able to speak for them selves; than we can think of how to present them; but yes, presentation is important also.
(16:55:14) mhu: yes, we agreed on that already: tuning for a version is short-term only; the real goal is indeed long-term (refactoring) improvements.
(16:57:37) liheng: will we discuss a example in OOo performance (maybe common hotspot), to define a set of benchmark
(16:58:51) mhu: back to tooling: maybe, for reporting we can make a small extension / addin for Calc to do the T-Test between two datasets; then we would have an initial presentation also ? just an idea.
(16:59:28) mhu: sorry, I needed to finish that idea first; what was your question wrt "example..."
(17:00:17) liheng: a sample for a hotspot or a key path
(17:01:17) mhu: and you want to discuss what about that sample? sorry, I have not yet understood
(17:01:47) xiuzhi: mhu: study a case in formance
(17:02:02) xiuzhi: liheng: does that your meaning?
(17:02:24) mhu: oh yes, we should study a case to learn what is going on and how to analyze and present it, yes.
(17:03:05) liheng: xiuzhi:thank you, i just try to find clear words:)
(17:03:33) mhu: maybe, for practical purposes, we start with a configmgr example?
(17:04:31) liheng: mhu:Of course!!!;) back to tooling: I want to setup a server for datasets:)
(17:04:34) mhu: that could be: Y=configmgr contribution to startup time, and we could try to find the major x's (hotspots) contributing to that Y by some f().
(17:05:23) mhu: yes, that server to store the measurement results was a good idea.
(17:06:48) mhu: ...we could also so a "synthetic" configmgr benchmark, not use startup time of entire office; I think yugq already wrote some "unit test" or "benchmark" ?
(17:07:26) yugq: mhu: yes
(17:07:46) liheng: so, it's good for persisting all data of teat
(17:07:57) liheng: sorry teat/test
(17:08:37) mhu: yes, if we want to learn something from the data, and other developers shall learn something of it, then it is good to store that data.
(17:09:07) liheng: okay, :)
(17:09:30) mhu: okay
(17:10:08) liheng: mhu:that all for me.
(17:10:27) mhu: yes, that's all from me also
(17:10:33) liheng: I wish you have a nice holiday
(17:10:41) mhu: thank you
(17:11:10) liheng: you are welcome, and see you at Aug 21th
(17:11:36) mhu: see you in three weeks, august 21.
(17:11:45) mhu: bye all
(17:11:47) xiuzhi: see you
(17:11:51) liheng: bye:)
(17:12:04) kuangliang: bye
(17:12:27) liangjun: bye
Performance/Meetings/2008/07/24
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/07/24
Time: 16:04– 17:03
Meeting No.:
Agenda:
(4:04:19 PM) liheng: hi,all
(4:04:27 PM) liheng: sorry, I'm late
(4:04:30 PM) mhu: Hi Liheng
(4:06:10 PM) liheng: mhu:yugq have some questions about creating a CWS
(4:06:16 PM) xiuzhi: hi all
(4:06:33 PM) liheng: yugq:please
(4:06:48 PM) liheng: sorry, please :)
(4:07:09 PM) yugq: oh, I created a CWS by EIS, the state is not correct.
(4:08:02 PM) yugq: and then, I created an issue, not checked yet.
(4:08:50 PM) yugq: I am just wait waiting for the issue being checked.
(4:09:28 PM) yugq: I don't know how to change the CWS state from "planned" to "new" so that i can use it.
(4:09:54 PM) mhu: sorry, can you give me 5 min? Someone just entered my room for a short discussion; I will be back soon, I promise...
(4:10:36 PM) liheng: of course
(4:13:39 PM) xiuzhi: yhgq: Did you post your ssh key to OOo to verify it ? please use linux console or cygwin on windows platform to create new CWS. please ask lijian about this kind of issue
(4:15:18 PM) yugq: xiuzhi, OK, I think i know the problem. Thanks! :-D
(4:15:26 PM) mhu: back again, sorry for that.
(4:16:13 PM) mhu: okay, yugq: creating cws...
(4:17:23 PM) mhu: ...I have not much experience doing that remotely via eis.services.openoffice.org (here in Hamburg I do that with command line tools that do contact the eis database internally)...
(4:18:13 PM) mhu: ...I think, if you have a problem with cws, please ask Martin Hollmichel for help (I hope he is available and not on vacation; xiuzhi ?)
(4:18:49 PM) mhu: ...but, of course I can look and see if I can understand the state of the cws...
(4:18:59 PM) xiuzhi: mhu: I asked one people to help yugq to solve this issue
(4:19:23 PM) xiuzhi: mhu:that is OK.
(4:19:31 PM) yugq: mhu, I think it's my mistake for using EIS to create a CWS. Is it possible for me to change the state CWS to "new" when it is now "planned"?
(4:19:32 PM) mhu: xiuzhi: okay, whom did you ask? So that I can talk to him ...
(4:20:08 PM) xiuzhi: mhu: one guy of our side
(4:20:25 PM) xiuzhi: mhu: we had same issue one year before.
(4:20:54 PM) xiuzhi: mhu: one guy from our side
(4:21:44 PM) mhu: oh, okay, I see. Maybe I can help anyway? What is the name of the cws?
(4:22:17 PM) yugq: mhu, the CWS name is "configtune00".
(4:22:22 PM) xiuzhi: mhu: sure, you can ask Martin H to do some help
(4:23:57 PM) mhu: okay, I will look at it, and ask Martin.
(4:24:09 PM) liheng: okay, we return to the discussion of "lock".
(4:24:12 PM) yugq: mhu, thank you!
(4:24:26 PM) mhu: yugq: you are welcome.
(4:24:49 PM) mhu: okay, the "locks" discussion...
(4:26:19 PM) liheng: so many locks in soffice, but all of them are necessary or not ?
(4:26:49 PM) mhu: I don't remember exactly where we ended with that discussion, but I had the impression that it was not clear about what you where talking and vice versa
(4:27:32 PM) mhu: well, you would need to analyze the design to find out whether a lock is necessary or not.
(4:28:17 PM) mhu: and, no, not all of them may be necessary. but to say which one is not necessary, you need to have a design.
(4:29:06 PM) liheng: Yes, it's just our opinion, sometime, we need some constraint of application of "Lock",
(4:29:33 PM) mhu: ooo is using multiple threads, and the UNO design rules say, that a UNO component needs to be thread safe.
(4:29:41 PM) liheng: can't use a lock if you have some misgivings
(4:30:32 PM) mhu: a new design to solve many of the problems with the original design (all components thread safe) is the "UNO Threading Framework".
(4:31:13 PM) mhu: but, this new design is not yet (widely) implemented in ooo.
(4:31:56 PM) mhu: but the goal is to have mechanisms / design that enables ooo to use more threading than it does today.
(4:32:42 PM) mhu: ...think of multi-core desktop cpus, all but one idle. what a waste of resources.
(4:33:20 PM) liheng: we are just thinking maybe we can create a set of tools to trace invalid "lock"
(4:33:51 PM) liheng: and clear them in last term of a release version
(4:34:02 PM) mhu: can you explain when is a lock "invalid" ?
(4:35:35 PM) liheng: a lock was created but it not safe any resource
(4:35:58 PM) mhu: can you explain what is a "resource"?
(4:36:51 PM) liheng: a share memory or handle
(4:36:53 PM) mhu: (sorry for asking these many silly questions; I only want to understand what you are thinking)
(4:37:16 PM) mhu: memory shared with whom?
(4:37:33 PM) mhu: how do know it is not shared?
(4:38:15 PM) liheng: now , we don't know, but if we have some trace-tools ,we can find it
(4:39:04 PM) mhu: yes, this is what I am talking about: you dont find it, you do it by design and not by runtime analysis !
(4:40:00 PM) mhu: the lock may correctly be there by design
(4:40:53 PM) mhu: and there could tomorrow be a thread that requires the lock; that this thread is not there today, is irrelevant.
(4:41:30 PM) mhu: sorry for the harsh words, I dont know how to explain better
(4:43:06 PM) mhu: on the other hand, I know of cases where you proof that the design is over-engineered in that there is only one owner, and the resource not really shared..
(4:43:13 PM) liheng: okay, I see, but I still have some suspecting for it
(4:43:21 PM) mhu: ..in these cases you can of course eliminate the lock.
(4:44:28 PM) mhu: yes, I understand. you should suspect silly things with so many lines of code :-)
(4:45:35 PM) liheng: in a certain module (a job) we and desige it well, but if for all of OpenOffice.org, how to find the problem of locks, that is my thinking
(4:45:36 PM) liheng: :)
(4:45:51 PM) mhu: I think we will find (many) cases, where the design is inconsistent and a lock not really needed. But only a design analysis can proof that.
(4:46:32 PM) liheng: maybe it was only a suspecting
(4:47:16 PM) mhu: yes, you need to think about the entire design of ooo; that is what the "UNO Threading Framework" tries to do.
(4:48:33 PM) liheng: I need study deeply, but I maybe restart this topic again,,,,
(4:49:35 PM) liheng: please help us, to clarify it
(4:49:40 PM) liheng: ;)
(4:49:56 PM) mhu: yes, don't worry; I am sure we will discuss this again :-)
(4:50:20 PM) mhu: and I dont have a problem discussing this.
(4:50:28 PM) liheng: thank you,,that all for me
(4:51:35 PM) mhu: I dont have much either, maybe: do have anything new on the MID? why did you send the spec?
(4:51:50 PM) mhu: s/do have/do you have/
(4:52:36 PM) mhu: ah, I remember: that was xiuzhi's project(s), right ?
(4:53:05 PM) liheng: you ask for table of MID Device
(4:53:20 PM) liheng: on last discussion of it
(4:53:21 PM) liheng: :)
(4:54:05 PM) liheng: but we can't get Lenovo's table, so append table of BenQ to weekly report:)
(4:54:14 PM) xiuzhi: now ,liheng continue this project.
(4:54:54 PM) mhu: yes, I think these devices are interesting. and probably many people to use them in future (like mobile phones today).
(4:55:04 PM) xiuzhi: the project of lenovo is not over until now
(4:55:16 PM) mhu: did you try to run RedOffice / OOo on it?
(4:55:39 PM) liheng: OOo have been run on them;)
(4:55:54 PM) mhu: and does it run good / fast ?
(4:56:14 PM) liheng: not fast, but good for view a document
(4:56:14 PM) xiuzhi: it is not good on mobile phone
(4:56:27 PM) xiuzhi: MID is okay
(4:56:37 PM) mhu: I think, the major challenge is the small display size (800x480).
(4:57:23 PM) xiuzhi: but there are many challenges to this kind of Device. eg, the size and the speed
(4:57:27 PM) mhu: so, they are fast enough? maybe the new Intel Atom cpus are really not bad.
(4:57:31 PM) liheng: and lenovo's MID will be used by 2008 Beijing Summer Games
(4:57:34 PM) liheng: :)
(4:57:50 PM) liheng: can'
(4:58:11 PM) liheng: can run, and read, but not for long time using
(4:58:11 PM) liheng: :)
(4:58:17 PM) mhu: yes, I understand that you are / want to work with Lenove :-)
(4:58:33 PM) mhu: s/Lenove/Lenovo/
(4:59:39 PM) liheng: maybe all kind of MID :)
(5:00:33 PM) mhu: okay, that's it for today?
(5:01:00 PM) liheng: that all for me
(5:01:08 PM) xiuzhi: ok
(5:01:50 PM) liheng: mhu:see you next week
(5:01:52 PM) mhu: okay, then see you next week (after that, I am on vacation for 2 weeks, from aug 4 to aug 15 or so)
(5:02:03 PM) yugq: xiuzhi, I asked lijian for the problem of "CWS" right now.
(5:02:41 PM) xiuzhi: yugq: ok,
(5:02:44 PM) mhu: yugq: I will talk to Martin H.
(5:02:47 PM) yugq: ;-). thanks!
(5:02:56 PM) xiuzhi: yugq: did you know the reason?
(5:03:00 PM) mhu: okay, bye all, see you next week.
(5:03:03 PM) liheng: bye
(5:03:04 PM) yugq: mhu, thanks! It's my mistake.
(5:03:11 PM) xiuzhi: bye
(5:03:12 PM) yugq: mhu, bye.
(5:03:16 PM) yugq: bye all.
(5:03:17 PM) liangjun: bye all
Performance/Meetings/2008/07/17
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/07/17
Time: 16:02– 17:02
Meeting No.:
Agenda:
(4:03:00 PM) mhu: Hi all
(4:03:04 PM) kuangliang: hello mhu
(4:03:13 PM) yugq: mhu, hi
(4:03:35 PM) yugq: xiuzhi, hi
(4:03:48 PM) xiuzhi: hi all
(4:03:53 PM) xiuzhi: yugq:hi
(4:04:00 PM) kuangliang: hi xiuzhi
(4:04:29 PM) mhu: I am still reading the "configmgr refactoring" document that LiHeng sent out this morning.
(4:04:30 PM) liangjun: hi
(4:04:56 PM) liheng: hi,matthias
(4:04:59 PM) mhu: ...can you give a few minutes more time?
(4:05:06 PM) mhu: Hi LiHeng
(4:05:10 PM) liheng: sure,
(4:05:40 PM) mhu: okay, I am half through the doc; maybe 3-4 minutes...
(4:06:34 PM) xiuzhi: kuangliang:hi
(4:06:42 PM) xiuzhi: mhu:moin
(4:07:41 PM) liheng: please, i just read it , this morning (beijing time)
(4:07:42 PM) liheng: :)
(4:11:21 PM) mhu: so, I have now read the doc...
(4:11:33 PM) mhu: hello xiuzhi, moin :-)
(4:11:34 PM) liheng: mhu:Are there some problems with the document?
(4:12:07 PM) mhu: oh, I think it is a good summary of what we discussed so far...
(4:12:28 PM) mhu: ...and also a good plan of how to move on...
(4:12:49 PM) mhu: ...I still need to thing about 2 items: ...
(4:13:22 PM) mhu: ...one is the "security is not important" ... the other is the new "xml file format" ...
(4:13:53 PM) mhu: ...maybe, the first is what concerns me most.
(4:14:21 PM) mhu: but we dont need to discuss these points now.
(4:14:54 PM) mhu: generally it is a good design / plan.
(4:15:24 PM) liheng: mhu:ok ,we discuss these points via e-mail.
(4:15:32 PM) mhu: okay
(4:16:12 PM) liheng: Now, we can create CWS by this design for Configmgr,....
(4:16:54 PM) mhu: yes, I think you can go ahead, and start with a CWS.
(4:17:42 PM) liheng: as the same time , we change focus to common hotspot "lock".
(4:18:17 PM) liheng: yugq and liangjun have some points on it,
(4:18:39 PM) mhu: yes, go ahead please...
(4:18:48 PM) liheng: but , we are not sure on them,
(4:19:12 PM) liheng: liangjun:please, :)
(4:19:36 PM) liangjun: We find the OO implement one thread , and other thread was the help thread.
(4:20:34 PM) mhu: yes ?
(4:21:16 PM) liheng: liangjun:please put out some details
(4:21:54 PM) liangjun: The resource be usered in the main thread ,almost runing timer
(4:24:06 PM) liangjun: I think the help thread do not share resources with the main thread.
(4:25:04 PM) mhu: yes, most of OOo is single threaded (and not really) thread safe. only few threads are used by some thread safe components. configmgr is supposed to also be usable in a thread safe environment.
(4:26:15 PM) mhu: but I am not sure I know which "help thread" you mean (is that a single thread?)
(4:27:57 PM) liangjun: yes, I think.
(4:28:44 PM) liangjun: I mean the help thread is the thread n't the UI thread.
(4:29:06 PM) mhu: what does that "the help thread" do? do you have a call stack? who creates that thread?
(4:29:22 PM) mhu: sorry for so many questions...
(4:30:32 PM) mhu: I think there are more than 2 threads; there is the "main" (i.e. the first) thread, which is also the "UI thread", and then there are a couple more threads used by thread safe components...
(4:31:02 PM) mhu: ... so I dont know which "the (single) help thread" you could mean here; sorry.#
(4:31:03 PM) liangjun: yes .
(4:32:04 PM) mhu: liangjun: yes? is that not a too simple answer to so many questions ? :-)
(4:32:22 PM) liangjun: sorry, the help threads.
(4:32:29 PM) yugq: mhu, could you please explain the "thread safe components" more detail?
(4:32:46 PM) mhu: oh sure, sorry...
(4:33:55 PM) mhu: for example: in the sal/rtl/source/alloc*.c memory manager code, there is a thread flushing "caches" of memory blocks; the memory manager is a thread safe component...
(4:35:05 PM) mhu: another example would be the configmgr: it is a thread safe UNO component, and also uses a thread to (lazy) write back data to its files.
(4:35:33 PM) yugq: mhu, yes, understand. Thank you!
(4:35:57 PM) liangjun: I mean your two threads are help thread.
(4:36:09 PM) mhu: in general, all UNO components need to be (by definition) thread safe; some are not safe by design and use the "solar mutex" instead.
(4:37:10 PM) yugq: liangjun means the "flushing" thread a help thread.
(4:37:34 PM) mhu: liangjun: oh, I think now I understand: you are not talking about a single "help thread", but of multiple "helper threads" which exist for different amounts of time.
(4:37:59 PM) liangjun: mhu: yes .:)
(4:38:04 PM) mhu: :-)
(4:38:48 PM) mhu: so, yes. but they usually share data which their respective components; otherwise they would not be needed.
(4:39:50 PM) liangjun: I think the resource almost runing in the main thread .
(4:40:53 PM) mhu: and, of course, we need to think about using more than just one thread for the future (think "core 2 duo / quad" processors).
(4:41:32 PM) liheng: but, soffice.bin only can run in one processor
(4:41:45 PM) mhu: yes, but that needs to be fixed.
(4:42:18 PM) mhu: that is, I do want more parallelism, not less.
(4:42:40 PM) liheng: yes, sometime , some thread use mutex but it do anything on share resource
(4:43:39 PM) mhu: we dont need parallelism everywhere (that makes no sense), but central components like configmgr at least need to be thread safe; how it reaches that safety is implementation dependent.
(4:44:39 PM) liangjun: yes, but not all resource be shared .
(4:44:56 PM) mhu: yes, an implementation can be inefficient; than it can be improved; still it needs to be thread safe; but again: how it reaches that goal is a detail.
(4:46:13 PM) mhu: I am not sure I understand what you want to say: you dont want configmgr to be a thread safe UNO component?
(4:46:44 PM) mhu: or are you saying it's implementation of thread safety is inefficient?
(4:46:59 PM) liheng: mhu:this point is not only for ConfigMgr
(4:47:12 PM) mhu: I do believe the latter maybe true; and of course we should improve that
(4:47:21 PM) liangjun: oh , I mean the configmgr be called by only thread .
(4:47:42 PM) mhu: liangjun: that is surely not true
(4:48:05 PM) yugq: mhu, i think liangjun means, main thread and other thread do not share resource, so we don't need lock so much.
(4:48:35 PM) mhu: I am still not sure I understand
(4:48:54 PM) mhu: these thread do share a resource and that is the configmgr.
(4:49:03 PM) liheng: lock, is a wellknown hotspots, but soffice.bin have little thread, where is lots of lock come from??
(4:50:19 PM) mhu: are we talking about the granularity of locks in the current configmgr implementation? that can surely be improved.
(4:50:31 PM) liangjun: liheng: yes , we can reduce locking's count
(4:51:42 PM) liheng: mhu: sorry, we not only talk about comfigmgr's lock but also for whole OO:)
(4:51:55 PM) liangjun: mhu: I talking about the OO
(4:52:14 PM) mhu: but it must be possible for multiple (parallel) threads to access the configuration quasi simultaneously; that is, configmgr needs to be thread safe (as every UNO component); how it achives that thread safety, is an implementation detail: it can lock very fine grained or more coarse grained.
(4:52:25 PM) yugq: liheng, i think we need more discuss. As you said, "we are not sure on them".
(4:53:05 PM) liheng: yugq:yes
(4:53:33 PM) mhu: well, yes it is about all of OOo; I also think this needs more discussion; have you all had a look at the "UNO Threading Framework" ?
(4:54:12 PM) liheng: yes ,i have.
(4:54:43 PM) liangjun: mhu: sorry , I no . I only read current the OO source .
(4:54:49 PM) mhu: Okay, then you probably know what I have been talking about :-)
(4:55:31 PM) mhu: well, the current source is what we want to improve, right? it may not be how it should be.
(4:55:46 PM) liheng: but , it was all supports for threads, but i think there was few restrict
(4:56:12 PM) mhu: "few restrict" ?
(4:58:05 PM) mhu: I dont understand...
(4:58:08 PM) liheng: i means safety maybe lean on structure first
(4:58:51 PM) liheng: and then , it's a method to control like a "lock"
(4:59:41 PM) mhu: Can we continue this discussion via email, or in our next meeting? I have another meeting now ...
(5:00:11 PM) liheng: okay, thanks for your tips
(5:00:49 PM) mhu: thanks for an interesting discussion, and sorry for so many questions :-)
(5:01:04 PM) liangjun: mhu: thank you.:)
(5:01:25 PM) mhu: okay, then see you next week; bye all ... I need to hurry now ...
(5:01:30 PM) liheng: okay, see you next week, and thanks again
(5:01:35 PM) liheng: bye
(5:01:37 PM) liheng: :)
(5:02:22 PM) yugq: bye.
Performance/Meetings/2008/07/10
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/07/10
Time: 16:00– 16:58
Meeting No.:
Agenda:
(4:00:19 PM) liheng: hello,every one
(4:00:56 PM) liheng: mhu:hi mhu;)
(4:01:13 PM) yugq: hi
(4:01:58 PM) kuangliang: hi mhu
(4:02:40 PM) mhu: hi all
(4:02:47 PM) yugq: mhu,hi
(4:03:01 PM) liangjun: mhu::) hello
(4:05:23 PM) liheng: mhu: last week we talk about how to make OO's hotspot more static for measure
(4:06:26 PM) mhu: yes, we talked with xiuzhi (in Hamburg) about your document, that xiuzhi translated for me.
(4:06:59 PM) liheng: and we will make a thesis for OO Conference
(4:07:17 PM) mhu: and you proposed to make performance measurements more reproducable...
(4:07:49 PM) mhu: oh yes, a talk at the conference would surely be good
(4:08:05 PM) liheng: yes, So, we continue to talk about them.
(4:08:13 PM) mhu: yes
(4:09:20 PM) mhu: ...more reproducable by using a constant infrastructure (e.g. the same machine) for those measurements, right?
(4:09:29 PM) liheng: mhu:by the way, did you read michael Meek's new mail in performance mailinglist
(4:09:54 PM) mhu: LiHeng: yes, I've read it 20 minutes ago
(4:10:15 PM) liheng: It is looks some trouble with our network , so slowly :(
(4:10:40 PM) mhu: on last weeks ESC meeting (were xiuzhi was too) we also talked about (outstanding) performance work
(4:11:10 PM) mhu: okay, then I can writer faster than you :-) :-)
(4:11:29 PM) liheng: ahh, yes,;)
(4:12:25 PM) liheng: lots of performance works was in Michael's list
(4:12:39 PM) mhu: ...and mmeeks reminded us (me) of a project that I have started quite some time ago to optimize (and refactor) the "store" modules code.
(4:12:47 PM) liheng: but why they are not up-stream?
(4:13:41 PM) mhu: LiHeng: well, some of mmeeks changes are "controversial" (if not worse), some apply to Linux only, and so on and so on. almost none is without discussion.
(4:14:14 PM) mhu: ideas are usual good, but implementation not always so.
(4:15:25 PM) liheng: string interning is good way to reduce Consumption of memory during runtime
(4:15:33 PM) mhu: and, mmeeks engineers often only submit patches and dont want to do the CWS and QA work, so some changes simply lay around because noone does want to do the work of integrating them.
(4:16:20 PM) mhu: LiHeng: yes, I have no idea why the string-intern patches are not integrated, have not seen the details.
(4:16:48 PM) mhu: ...and mmeeks did most of the original string-intern work.
(4:17:17 PM) mhu: ...so I dont know why is not doing the rest as well, but waits for others to do it
(4:17:20 PM) liheng: oh, Now i see, but if we do right of his idea, we can integrated them in a CWS by CH2000
(4:17:57 PM) mhu: yes, why not. we can take patches, review them and if they are good, integrate them
(4:18:38 PM) liheng: by the way, I just applied 3 persons jion us, we get strong;)
(4:19:00 PM) mhu: oh good to hear that :-)
(4:20:58 PM) liheng: yes, For a long time I think we need more and more people to jion us, so I apply to my company to expand us, and we get right;)
(4:22:02 PM) liheng: but It spent my 3 weeks time,
(4:22:25 PM) mhu: I think you are right; and I also think xiuzhi got a new impression last weel of how much work there still is to do (performance, modularization, ...)
(4:22:40 PM) mhu: s/weel/week/
(4:23:06 PM) mhu: yes, you spent 3 weeks ... ?
(4:23:37 PM) mhu: ah, it took you 3 weeks to get the 3 more people ?
(4:23:49 PM) liheng: yes , 3 weeks , talk, discuss, plan,
(4:24:11 PM) mhu: okay, understood; that's life for a project lead I guess :-)
(4:24:48 PM) liheng: except my technical job
(4:25:34 PM) mhu: yes
(4:25:37 PM) liheng: so, if you find some patch and idea that maybe improve OO's perform, we can try it and test , then start a CWS integrate them
(4:27:11 PM) liheng: back to topic "more reproducable by using a constant infrastructure for those measurements"
(4:27:24 PM) mhu: okay
(4:28:58 PM) liheng: i think we need a standard for comparing
(4:29:20 PM) liheng: same machine is a part of it
(4:30:54 PM) liheng: in simply profile, we can only find simple hotspots
(4:31:01 PM) mhu: yes, "same machine" was meant as an example, only. the important part, as you say, is " standard".
(4:32:46 PM) mhu: ...simple profile...simple hotspots... ?
(4:35:11 PM) liheng: simple profiling means run a profile tools for several modules but you can not confirm its efficacy
(4:37:07 PM) mhu: okay, I think I understand.
(4:37:27 PM) mhu: do you have ideas how to improve that?
(4:37:37 PM) liheng: and we can only find "strcmp" and "locks" is hotspot , it's "simple hotspots"
(4:38:24 PM) mhu: ah yes, you mean functions that consume much time because they are called so many times ?
(4:39:41 PM) mhu: ...and assuming that "strcmp" for example is already optimized, the true hotspot is the code that calls strcmp so many times ?
(4:39:42 PM) liheng: yes, but we don't comfirm the cause in up-level
(4:40:07 PM) liheng: yes
(4:40:09 PM) liheng: !
(4:40:19 PM) mhu: oh well, sometimes it is done; but you are right, we dont do that often enough.
(4:40:37 PM) liheng: it's the matter we must refactor for
(4:40:39 PM) liheng: ;)
(4:40:47 PM) mhu: yes, we agree.
(4:42:29 PM) liheng: so, before if, we need a benchmark-system to find and verify our target
(4:43:22 PM) liheng: sorry , before it,
(4:43:26 PM) liheng: not if
(4:43:43 PM) liheng: so many type error today
(4:43:44 PM) liheng: :(
(4:43:46 PM) liheng: sorry
(4:45:31 PM) mhu: dont worry, when I write too fast, I do make many typos also
(4:46:33 PM) mhu: yes, benchmark (system); an initial attempt is the cws performance tests, that Malte sent to you.
(4:46:46 PM) mhu: ...but that is probably not enough
(4:46:59 PM) mhu: ...and needs to improved / extended
(4:47:12 PM) mhu: s/needs to/needs to be/
(4:47:23 PM) liheng: yes , it's my opinion.
(4:47:41 PM) mhu: okay
(4:49:19 PM) liheng: we need a set of benchmark, that can find the changes between several versions, and split them from static to dynamic points
(4:50:02 PM) mhu: yes, agreed. that was my question: do you have ideas how to achieve that?
(4:52:23 PM) liheng: Yes, at first we optimize basic modules or objects, and make some benchmarks for them to measure them individual
(4:54:07 PM) mhu: ah yes, for example: not only measure total startup time, but also contribution of configmgr (for example) and take action if measurable changes occur.
(4:54:41 PM) liheng: yes, ;)
(4:54:43 PM) mhu: ...and that for more modules individually. yes.
(4:54:47 PM) mhu: okay.
(4:55:22 PM) mhu: sorry to say so, but I have the next meeting in 5 minutes. so I need to close sharp today.
(4:55:56 PM) liheng: then, we cache information of the basic modules, and put the information into up-level benchmark, then, we can get some sign
(4:56:52 PM) liheng: Okay, the draft of thesis will be sent to you when we complete it
(4:57:20 PM) mhu: okay, yes please send it to me; I will read it with interest.
(4:57:21 PM) liheng: all opinion and method will be in it
(4:57:33 PM) mhu: good.
(4:57:43 PM) liheng: so , that all today
(4:57:50 PM) liheng: thank you ;)
(4:57:59 PM) mhu: okay, I have to leave now, heading to another room on another floor...
(4:58:13 PM) mhu: thank you. bye all, see you next week.
(4:58:34 PM) yugq: mhu, See you.
(4:58:39 PM) liangjun: :)bye
(4:58:50 PM) liheng: bye
(4:58:52 PM) liheng: :)
Performance/Meetings/2008/07/03
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/07/03
Time: 15:00– 15:58
Meeting No.:
Agenda:
(15:00:42) LiHeng: hi,xiuzhi, how about our ID?
(15:01:46) xiuzhi: Liheng: matthias is not in
(15:02:02) xiuzhi: he will be here in several minutes
(15:02:15) LiHeng: okay,
(15:02:38) xiuzhi: 9:00 is a little early to him ,maybe
(15:02:46) LiHeng: xiuzhi:thank you for your translation
(15:03:30) LiHeng: xiuzhi:how about our ID? we have no ID like xx@openoffice.org
(15:03:33) xiuzhi: LiHeng:my pleasure
(15:04:08) LiHeng: where did you apply it ?
(15:04:27) xiuzhi: LiHeng: that is liheng@openoffice.org and yugq@openoffice.org. you can log in openoffice.org using that account
(15:04:51) yugq: xiuzhi, hi. hi all.
(15:05:05) LiHeng: ahh,:-(, we didn't know it
(15:05:06) xiuzhi: yugq:hi ,afternoon
(15:05:33) LiHeng: xiuzhi:you are in morning:)
(15:05:47) xiuzhi: Please see :http://www.openoffice.org/servlets/Login?cookieCheck=on
(15:06:23) yugq: xiuzhi is in Germany?
(15:06:32) LiHeng: liangjun:what is your ID on OpenOffice.org?
(15:06:49) liangjun: :)
(15:07:15) LiHeng: yugq:yes he went to harnbag last week
(15:07:37) liangjun: zengliangjun@RedOffice.com.cn
(15:07:39) yugq: wow, :-D
(15:07:40) xiuzhi: LiHeng: and Matthias want to know the meaning of "same platform" and "does the reconstruction mean a long-term plan"
(15:07:59) xiuzhi: yugq:sure
(15:08:23) xiuzhi: LiHeng: Please see my yesterday's email
(15:08:41) xiuzhi: LiHeng: that is one of the topics today
(15:09:08) yugq: xiuzhi, it seems I can't use yugq@openoffice.org to log in openoffice.org.
(15:09:41) xiuzhi: yugq:really? I have tell Martin this account. Please try again
(15:09:46) liangjun: your mail has been changed
(15:09:48) xiuzhi: or regist again
(15:10:01) liangjun: yugq:your mail has been changed
(15:10:35) yugq: I'll try it again.
(15:10:43) LiHeng: I have already read your translation. "same platform" means we want to build a lab for performance on internet, all of OO developers can submit his version and CWS, and that get the report based same platform
(15:11:12) LiHeng: xiuzhi:can you understand my explaination
(15:11:59) xiuzhi: LiHeng: not really
(15:12:15) LiHeng: not really?
(15:12:47) xiuzhi: same platform: the same OOo milestone?
(15:13:02) xiuzhi: that is my and Mhu's understanding
(15:13:35) xiuzhi: mhu is in now. we can start the meeting soon
(15:14:54) LiHeng: :)
(15:15:49) xiuzhi: or same platform: the same OOo Master workspace milestone., the performance evluation of every CWS should based on one same OOo milestone.
(15:16:05) LiHeng: mhu:hi, good morning
(15:16:08) mhu: Hi all, sorry for being so late (traffic :-( )
(15:16:16) yugq: mhu, hi!
(15:16:23) liangjun: mhu:hi:)
(15:16:31) LiHeng: mhu:so long time to see you again
(15:16:43) mhu: Hi LiHeng, yugq, liangjun
(15:16:54) mhu: yes, 2 weeks?
(15:17:04) LiHeng: 2 :)
(15:18:00) LiHeng: mhu:we just talk about "same platform";)
(15:19:01) mhu: yes, xiuzhi and I had some discussion yesterday; some words seem to be unclear ti us.
(15:19:17) mhu: s/ti us/to us/
(15:20:10) xiuzhi: yugq: try" yugh" to log on http://www.openoffice.org/servlets/Login?cookieCheck=on
(15:20:24) yugq: I think LiHeng means the "same platform" mostly like "unitive platform".
(15:20:30) yugq: xiuzhi, OK.
(15:20:30) LiHeng: In my opipion,to measure performance of OO, we should run all testing cases on same machine, and same state within
(15:21:25) mhu: Ah, I see. "same platform" = "same machine + state"
(15:21:43) xiuzhi: LiHeng: same hardware and software environment/context?
(15:22:34) mhu: this sounds like a "virtual machine" like "VirtualBox".
(15:22:35) LiHeng: we want build a lab to provide it on internet for OO
(15:23:07) LiHeng: mhu: :) ,yes, cache snapshot and some state we need
(15:23:28) yugq: xiuzhi, what is my password?
(15:23:36) mhu: yes, that's what I mean :-)
(15:23:54) xiuzhi: yugq: that is yours, I donot know
(15:24:50) LiHeng: xiuzhi:mhu and I think the "same platform=same machin + state"
(15:25:15) xiuzhi: LiHeng:ok,
(15:26:13) yugq: xiuzhi, are you sure my id is "yugh"? I can't login:-(
(15:26:57) mhu: yugq: can you also try "yugq@openoffice.org" ?
(15:27:10) xiuzhi: yugq: that is your account. I do not know . if you cann't log in, please regist again
(15:27:44) LiHeng: mhu:and "the reconstruction mean a long-term plan" means refactor
(15:29:23) yugq: xiuzhi, mhu, I know now. I thought you assigned a new id for me. Sure, I can login with "yugq", which is my id always used.:-D
(15:29:52) LiHeng: i means refactor need a lot of work in following version and make OO framework well and delicate step by step
(15:31:03) mhu: LiHeng: Ah, I see. "refactor" to me sounds better than "reconstruction" (where I often think "chart2").
(15:32:06) mhu: yes, refactoring can be a lot of work. But I also do not see much alternative. Many code cannot stay (for long time) as it is now. It needs refactoring.
(15:33:34) LiHeng: Yes, i am agree, but in another aspect, refactor can make OO delicate but fast
(15:34:29) LiHeng: so for performance we must confirm every refactoring planing make OO faster (at least not slower) ;)
(15:35:04) mhu: sure, we want to use refactoring to make it faster (but also "better" in terms of functionality, quality, maintainability,. ...)
(15:35:36) mhu: yes, it shall not get slower, of course :-)
(15:37:13) LiHeng: so, i think refactor of OO need discuss in a large scale to make hotspot static
(15:38:23) mhu: yes, I agree.
(15:40:17) LiHeng: lots of work maybe don't effect to performance directly, but they can make hotspot locating easily and stably
(15:41:36) LiHeng: and that ,all people can find problem of performance and deal it individual
(15:42:33) mhu: yes, that may be. Do you have some ideas how to achieve that?
(15:44:34) LiHeng: some, so i am experimenting for them
(15:46:27) mhu: okay, maybe we can discuss these idea when you're experiments have shown some results.
(15:47:17) LiHeng: so, at least we must improve performance tools of testing for CWS, comparability is important things for it
(15:48:17) mhu: yes, that is true. these tests need to function properly.
(15:49:01) LiHeng: that comparabiliy is not only for a CWS but also can do comparing between servsal
(15:49:46) mhu: ...between several... what ? releases ? like 2.3.0, 2.3.1, ...
(15:50:19) LiHeng: and Performance Group mark some statistics for report some problem would be existing
(15:51:13) LiHeng: mhu:may be, but several CWS for 2.3.0 or a major version
(15:51:41) mhu: yes, problem detection and reporting is indeed important.
(15:52:29) mhu: ah, okay. ...between several... can also be several CWS, yes.
(15:55:23) LiHeng: yes, next week we discuss some idea of tools and feasbility of lab on internet
(15:57:02) mhu: okay, fine.
(15:57:18) LiHeng: i will send some details of them to you (maybe yugq will send it to you, i am gloomy for mailbox recently )
(15:57:37) mhu: sorry, but xiuzhi and I are now expected to go to the OOo ESC meeting here in Hamburg.
(15:57:51) mhu: LiHeng: yes, please send it via email.
(15:57:57) LiHeng: okay , that all
(15:58:33) mhu: okay, then see you next week. have a nice afternoon / evening.
(15:58:43) mhu: bye all
(15:58:44) LiHeng: thank you,:)
(15:58:45) LiHeng: bye
(15:58:50) yugq: mhu, bye.
