Performance/Meetings/2008 06
|
|
|---|
|
Quick Navigation Team Communication Activities |
| About this template |
Contents
Performance/Meetings/2008/06/26
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000 and the Community ??
Performance Project
Date: 2008/06/26
Time: 16:05– 16:40
Meeting No.:
Agenda:
(4:05:56 PM) liheng: Hi,all
(4:05:57 PM) erAck: ah, answer arrives ;)
(4:06:06 PM) Matthias: and there they are :-)
(4:06:20 PM) liheng: sorry,I'm late
(4:06:37 PM) erAck: np, good afternoon
(4:06:38 PM) liangjun: :) Hi all
(4:06:42 PM) Matthias: liheng: hi, dont worry
(4:06:51 PM) yugq: hi all
(4:08:25 PM) liheng: Matthias: Welcome to you come back, How about your vacation? :)
(4:10:23 PM) Matthias: liheng: that was a very good vacation time, thanks
(4:10:41 PM) liheng: You are welcome!
(4:10:49 PM) liheng: Let's update our status.
(4:12:10 PM) ***Matthias status is simple: still couple hundred emails left to read after returning from vacation; will report cws mhu20 status next week latest
(4:13:01 PM) erAck: my status: solving OOo3.1.1 puzzles.
(4:14:08 PM) cd_oo: my status: CWS fwk108 which contains start up improvements for Writer and an optimization for the SfxVoidItem is "nominated". CWS fwk112 which contains the non-rebased library optimization for Windows is "Ready for QA".
(4:14:20 PM) liheng: My Status:I and yugp rebuild the user interface for BenchmarkSystem,we add user management to support that you can trace and save your Benchmark rawdata on web ...
(4:16:23 PM) liheng: ... and we start to trace changes between m44 and 00o3.1 to verify all work is effective in performance
(4:17:41 PM) liheng: I'm also working for replacing the wiki of performance,but I found lots of information in it. :(
(4:20:02 PM) Matthias: replace the wiki? why? replace with what ? can you explain, please ?
(4:20:16 PM) liangjun: My Status: continue odf document load performance , and it's slow :P
(4:23:28 PM) liheng: Several weeks ago, we talk to rearrange the first wiki page of performance, so that we can easy to trace status, effectivity and progress of our work...
(4:24:52 PM) liangjun: I plan to use three strategy: serial / parallel / delay processing
(4:25:37 PM) liheng: So, I start this work with my colleague about two weeks before, but we found lot's of pages and information in old.
(4:26:46 PM) Matthias: liheng: ah, rearrange the wiki pages (not replace). that is fine with me.
(4:27:40 PM) liheng: Sorry, I used ambiguous words.
(4:34:06 PM) liheng: Ok, if no more topic ,can we close meeting early today?
(4:34:39 PM) ***Matthias had a very similar question :-)
(4:35:03 PM) Matthias: yes, I dont have more for today
(4:35:16 PM) erAck: fine with me
(4:35:34 PM) liangjun: me too
(4:36:50 PM) cd_oo: ok
(4:37:43 PM) erAck: bye all!
(4:39:06 PM) cd_oo: bye all
(4:39:25 PM) Matthias: okay, then see you next week, have a nice weekend, bye all
(4:39:55 PM) liheng: Okay, see you next week.bye all
Performance/Meetings/2008/06/19
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/06/19
Time: 16:02– 16:13
Meeting No.:
Agenda:
(16:02:46) LiHeng: Hi, my network is not good enough:)
(16:03:02) LiHeng: where is Xiuzhi?
(16:04:54) yugq: He is not in his seat.
(16:05:36) LiHeng: Okay,maybe he have another meeting with Boss;)
(16:06:16) LiHeng: mhu:did you receive the email about topic today
(16:06:44) LiHeng: mhu:I says sorry for it was late.
(16:06:54) mhu: LiHeng: yes, I have read your agenda, as well as yugq's email to the mailing list.
(16:07:15) mhu: Oh, don't worry being late; usually, it is me who is late.
(16:07:49) LiHeng: I'm not in office recently, and our mailbox has lots of trouble since it was change to "redoffice.com.cn":(
(16:08:30) yugq: I will be better later.;-)
(16:08:33) mhu: okay, don't worry; as long as it works somehow, we can work.
(16:09:29) LiHeng: thank you, today we have only one major topic about "locking" that was mentioned by Michael
(16:09:40) LiHeng: yugq:please:)
(16:09:48) yugq: OK.
(16:10:05) mhu: yes, and I think you are right: we cannot improve with (fine) tuning hot spots only.
(16:10:56) yugq: From MMeeks' mail, he metioned the "Locking" problem, "locking" is a hotspot. And from the profile data from callgrind, configmgr contributes a lot to "locking" also.
(16:10:56) mhu: that is why we have started this project, to do some deeper analysis and fix things better than just "tuning"
(16:11:31) mhu: yugq: yes, Michael is right here, it is indeed a well known hotspot.
(16:11:35) LiHeng: mhu:yes :), we must make a large scale refactor in following versions to improve performance step by step
(16:12:10) yugq: Configmgr's locking problem mainly comes from binary read and string operations.
(16:13:21) mhu: Michaels approach is the well known (open source) "bazaar" principle of "many small incremental changes" in the end give a good product. And while that is surely true, it is not always the best approach to solve problems.
(16:13:27) yugq: And another big contribution to "lock" comes from UNO concerned operation.
(16:13:54) mhu: yugq: yes, as far as I remember, your analysis is correct.
Performance/Meetings/2008/06/12
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/06/12
Time: 16:00– 17:02
Meeting No.:
Agenda:
(16:00:29) LiHeng: Hi, everyone
(16:00:43) mhu: Hi all
(16:00:55) LiHeng: Hi,matthias
(16:01:12) mhu: Hi LiHeng
(16:01:20) liangjun: mhu: hi
(16:01:41) mhu: Hi liangjun
(16:01:48) LiHeng: mhu:Did you receive the weekly report?
(16:02:00) xiuzhi: hi all
(16:02:06) mhu: LiHeng: yes, I have received and read it, thanks.
(16:02:18) mhu: Hi xiuzhi
(16:02:27) xiuzhi: mhu:hi ,moin
(16:02:33) mhu: moin :-)
(16:03:28) mhu: xiuzhi: you have many irc meetings with martin hollmichel ? (moin)
(16:03:59) xiuzhi: mhu: sure
(16:04:19) xiuzhi: mhu: I hope to meet you next month
(16:04:20) mhu: that's what I thought.
(16:04:42) mhu: xiuzhi: Ah yes, you are coming to Hamburg, right?
(16:05:08) xiuzhi: mhu: I hope so, but I am not sure the visa, time is very urgent
(16:05:23) mhu: xiuzhi: ah, I see.
(16:05:38) LiHeng: mhu:At first, we continue to discuss about shared configure and administrator's operations.
(16:05:53) mhu: LiHeng: okay, please go ahead.
(16:07:32) LiHeng: we confirm that there are still some finialize item in configures but they are removed into Basic3.0 directary in OO3.0 :)
(16:08:52) LiHeng: Then, now, we have to talk about , which operations admin work on they
(16:09:32) mhu: Hmm, do you mean "removed" (i.e. "away"), or do you mean "moved to Basic directory" (i.e. they are somewhere else, but still there) ?
(16:10:08) LiHeng: mhu:yes! sorry for type
(16:10:11) LiHeng: :(
(16:10:41) mhu: okay, no problem; but which one do you mean? "moved to ..." ?
(16:11:36) LiHeng: they are moved into Basic directory now
(16:12:04) LiHeng: so they are still existing
(16:12:05) LiHeng: :)
(16:12:28) mhu: ah, okay. But then effectively nothing has changed, except the location (but not the meaning), right ?
(16:13:21) LiHeng: a little items were changed. but it is not important for us
(16:14:03) mhu: So, from what I understand, this installation change is done to better separate "URE", "Basic", and "Brand".
(16:14:39) xiuzhi: sure,
(16:15:17) LiHeng: mhu:Yes, and that we have to talk about which operations admin work on them, one important thing is when user modify a configuration setting .....
(16:15:56) mhu: So, we still want to find a possibility to store the merged configuration data as a single item in the users directory, and at the same time allow an administrator to "fix" some settings, so that a user cannot change them, right ?
(16:16:17) mhu: sorry, I just read that you wrote the same as I :-)
(16:17:50) LiHeng: for item user cann't change we reach a consensus, but are there some items can be changed by both user and admin?
(16:17:53) mhu: can we think of a (generic) way to allow an administrator to "fix" any setting she likes, or do we need to define a few settings ?
(16:19:21) mhu: changed by both user and admin? I think that would be the initial (template) data? But not at runtime, where user changes always win ?
(16:20:12) LiHeng: if an administrator to "fix" any setting, we must confirm how to deal the setting that would be changed by a user?
(16:20:44) LiHeng: Oh,yes , I see all of yours, ...
(16:21:15) mhu: if the item is finalized by admin, I think user cannot change it ( or when he changes it, it will be reverted back to the admin setting)
(16:21:45) LiHeng: That admin can change any setting for new user , and a user will get the initial setting when he setup,...
(16:22:04) mhu: yes, that was I idea, I think.
(16:22:27) LiHeng: then user can change settings but some setting don't be allowed?
(16:22:35) mhu: yes
(16:23:29) LiHeng: okay, we complete all requirements for shared copy of configuration :)
(16:24:34) mhu: maybe, the set of "finalized" configuration (dom) nodes can be read from the "share" directory / layer. If there is no such file (nodes), then startup maybe faster (no need to merge).
(16:24:53) mhu: just a spontaneous idea...
(16:25:13) LiHeng: that you for your patience
(16:26:18) mhu: oh, design / architecture via irc is something new for me; so thank you for your patience :-)
(16:26:36) LiHeng: mhu: yes , will design some mapping for get static setting
(16:26:50) mhu: okay
(16:27:56) LiHeng: after, this job we will design/ architecture via email ,but now we must try to walk on same way!
(16:28:22) mhu: and, when we have a more concrete idea, and maybe proof of concept implementation, we should probably also discuss this in public, so that others can raise their voice just in case we forgot something important.
(16:29:20) mhu: LiHeng: can you repeat please, I am not sure I understand ?
(16:29:26) LiHeng: yes, we will public the requirements to mailing list
(16:30:08) LiHeng: configmgr refactor is the first job working with you, ...
(16:30:26) mhu: yes...
(16:31:06) xiuzhi: publicing the discussing result is a good idea.
(16:31:32) LiHeng: so we worry about we can't in same method of working
(16:32:09) mhu: LiHeng: "walk on same way" ? "method of working" ? can you explain? do you see a problem?
(16:33:53) LiHeng: no problem now :)
(16:33:56) mhu: I think, you can simply go ahead how you want to work, and I will try to help as much as I can; is that okay for you?
(16:34:08) mhu: LiHeng: okay :-)
(16:34:49) LiHeng: i mean we adapted style of work with OO
(16:34:55) LiHeng: ;)\
(16:35:18) mhu: okay
(16:37:56) xiuzhi: something wrong with LeeH's network, I think
(16:38:39) mhu: yes, this happened previously also; shall we wait a few minutes?
(16:39:39) xiuzhi: I will call him.
(16:40:06) mhu: xiuzhi: by the way, you sometimes write "Lee" instead of "Li"; are these two forms equivalent?
(16:40:27) xiuzhi: ok now
(16:40:43) LiHeng: mhu:sorry, i am just down
(16:40:43) mhu: welcome back...
(16:40:44) xiuzhi: mhu: yes.
(16:40:55) mhu: xiuzhi: okay, thanks.
(16:41:33) LiHeng: xiuzhi:please save the log, my irc has just crashed!
(16:41:43) xiuzhi: LiHeng:ok
(16:42:13) LiHeng: mhu:we want to get your opinions about " it is well known the hotspot is dynamic in different versions, and lots of persons and teams work on it. But all kinds of performance problems has existed in OO. So there is little effectivity on performance improvement by individual teams. "
(16:42:13) mhu: hopefully, I also have a copy of the log, if it helps.
(16:43:31) mhu: LiHeng: yes, I read that in some of your emails; I think this is generally a valid observation; do you want more detailed comments?
(16:45:37) LiHeng: i am making a plan to change the state, but it need a lot of work and supporting of OO
(16:46:42) mhu: yes, it does indeed need a lot of work; that is why some (technically possible) performance improvements have not been done in the past.
(16:47:31) LiHeng: if we want to impove performance of OO completely, we must change some method of developement or make some addition process into
(16:47:33) mhu: I think, you will have the (moral) support of almost all users; specific support from developers is sometimes more difficult to get
(16:48:22) mhu: do you already have some ideas about changing the development (process)?
(16:49:04) LiHeng: a little , but it's not whole plan,
(16:49:07) LiHeng: ;)
(16:49:19) mhu: [one of my ideas would be more design reviews before someone implements something that makes OOo slower]
(16:49:43) mhu: yes, I also do not (yet) have a whole plan.
(16:50:40) mhu: [but those design reviews would be a very centralized approach, and might not scale with many simultaneous CWS that are underway]
(16:50:51) LiHeng: yes, most important is review, but it would not not be in point , must check whole
(16:51:43) mhu: yes, that is also what I mean: a review against the whole design (each piece must fit into the puzzle somewhere)
(16:52:07) LiHeng: we need some mechanism to check and compare values of testing automic
(16:52:31) mhu: yes, I think we already agreed on that
(16:52:37) LiHeng: and publish to all of develop teams
(16:53:15) mhu: yes, if everyone can see the results (and knows that others can see that too) it might help raising awareness.
(16:54:08) LiHeng: and separate tuning and refactor make the plan for following several version
(16:55:00) mhu: LiHeng: are there some words missing in above sentence?
(16:55:44) LiHeng: Yes :)
(16:56:05) mhu: okay, can you rephrase it, please?
(16:57:01) LiHeng: For tracing improvement of performance , we must determine the targets of every version and separate tuning and refactor make the plan for following several version
(16:57:02) LiHeng: :)
(16:57:03) mhu: you think of a more long term plan, including time for refactoring and tuning (like we now have for localization)?
(16:58:17) mhu: okay, and also a target (of improvement; say, 10% faster startup ?) for each version seems to be good.
(16:58:17) LiHeng: mhu:today, it's time out, i send a part of plan by email , in next weekly report
(16:59:00) mhu: okay, I think we are not so far away in what we think is the right thing to do. I wait for your email, thanks.
(16:59:25) LiHeng: 10%, 20% on the premise that it must be measurable :)
(16:59:44) mhu: yes, of course measurable :-)
(17:00:05) LiHeng: okay, that's all:)
(17:00:10) LiHeng: good luck
(17:00:15) mhu: that was only an example of a "target"; it can also be 100% if you like that number better :-)
(17:00:34) mhu: okay, then see you next Thursday?
(17:00:56) LiHeng: yes, next Thursday
(17:01:04) liangjun: bye :)
(17:01:11) mhu: okay, then bye all.
(17:01:21) LiHeng: bye
(17:02:02) xiuzhi: see you next Thursday
(17:02:21) mhu: bye xiuzhi
(17:02:31) xiuzhi: mhu:bye
Performance/Meetings/2008/06/05
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2008/06/05
Time: 16:09– 17:20
Meeting No.:
Agenda:
(16:09:58) LiHeng: Hi, mhu
(16:10:19) mhu: Hi all, sorry for being late (again) :-(
(16:10:25) liangjun: mhu: hello
(16:11:05) kuangliang: hello mhu
(16:12:02) LiHeng: Don't mind. mhu, I'm late too, just earlier a little than you
(16:12:43) LiHeng: I'm not in company , so there are some trouble with WIFI here:)
(16:13:05) mhu: okay.
(16:13:41) LiHeng: mhu:Did you receive the email that have tipocs for today?
(16:14:34) mhu: yes, I have read the agenda, and also the "Configmgr Refactor" document.
(16:16:10) LiHeng: Do you think about those requirements are enough to new configmgr?
(16:17:49) mhu: generally yes, but I think I have a few comments and questions...
(16:19:19) mhu: (a) I am not sure that the merged tree needs to be a "binary cache" (it could possibly also be a single large xml file that is fast to load and parse).
(16:20:44) mhu: (b) I am not sure that I really mean "readonly" and "security" only; probably it is called different but there is a concept of "finalized" and a concept of "shared" meaning that a user cannot change it.
(16:23:27) mhu: (c) the small amount of "readonly" / "shared" items needs of course be merged at every startup (at least), and is probably still xml (xcu); that's why I think merging means merging the dom nodes, and the merged result can again be (saved as) a single large xml file.
(16:24:16) mhu: That's it for the moment; generally a good idea, maybe I did not yet understand everything of your details.
(16:26:13) LiHeng: About the (a), we had design a format of merged data, no problem, we also want to make it to formed a xml, but now OO is binary cache,
(16:27:24) mhu: okay, I think you can make it xml; the current binary cache is only a helper implementation detail; it does not need to remain.
(16:27:59) LiHeng: okay, i think so.:)
(16:30:11) LiHeng: and (b)and (c) would be same problems for me, and it is putted on the agenda at first by me.
(16:30:27) mhu: as long as the performance is good, you can save everything to a single xml file (probably majority of slowly chaniging items); there maybe fast changing items (WindowState.xcu's ?), that should probably go into smaller individual files?
(16:30:59) mhu: ah, okay; yes (b) is (c) is probably the same, you are right.
(16:31:37) xiuzhi: hi all
(16:31:47) mhu: Hi xiuzhi
(16:31:53) xiuzhi: sorry for late
(16:31:58) xiuzhi: mhu:moin
(16:32:03) LiHeng: xiuzhi is coming now
(16:32:04) mhu: moin :-)
(16:32:13) LiHeng: hello, xiuzhi
(16:32:28) xiuzhi: LiHeng:hi afternoon
(16:32:29) liangjun: xiuzhi:hello
(16:32:43) xiuzhi: liangjun:how are you
(16:33:03) LiHeng: xiuzhi: we just talk about the "readonly"/"shared" item in configmgr
(16:33:41) xiuzhi: LiHeng:see . I looked your agenda and last meeting minutes
(16:34:48) LiHeng: mhu:As I saw from (b), finally we just need "Readonly"/"Shared" Item for administrator
(16:36:35) LiHeng: and in answer (c), you think those items would be loaded at startup for flush the "Shared" setting, right?
(16:37:57) mhu: LiHeng: yes, "administrator" owns those items...
(16:38:43) mhu: ...and yes, they would be merged "over" (possibly conflicting) user settings.
(16:40:48) LiHeng: last question for shared item. Do you means all of items admin owns that couldn't be modified by other users? But now oo have no such item in
(16:44:33) LiHeng: mhu:last question for shared item. Do you means all of items admin owns that couldn't be modified by other users? But now oo have no such item in
(16:44:58) mhu: are you sure? I have just grep'ed over a shared registry; there are lots of "oor:finalized=true" items?
(16:47:59) LiHeng: i mean I not sure that the all shared items couldn't be medified by other users
(16:48:47) mhu: no, not all; I am talking about "share/registry/data/org/openoffice/Office/Paths.xcu" for example, which has a couple of "oor:finalized=true"
(16:49:52) mhu: (another file is same path, but "Label.xcu")
(16:52:34) LiHeng: in "oo-dev 3" has no Paths.xcu in share/registry/data/org/openoffice/Office/ now (at least in my machine)
(16:52:34) mhu: (but, when I look at it, "Labels.xcu" is probably not critical; making no difference whether a user modifies it or not)
(16:53:20) mhu: oh, I took some old (2.x, x unknown) installation...
(16:54:46) mhu: ...maybe I have missed a couple of changes to the configuration (?)
(16:55:31) LiHeng: we will comfire it tomorrow
(16:55:39) mhu: ...but, that does still not mean, that another layer / backend could not make use of that "finalized" attribute.
(16:56:30) mhu: ...and if an admistrator wants to preconfigure an installation, it can still make sense.
(16:56:39) mhu: ...at least I think so.
(16:57:40) mhu: yes, please confirm (with whom?) whether is "finalized" concept is still there.
(16:58:02) mhu: s/whether is/ whether this/
(16:58:26) LiHeng: yes, i will
(16:58:33) mhu: okay, thanks
(16:59:56) LiHeng: in theory, when a user changed status of a item, administrator couldn't flush it with Share configure,do you think so ?
(17:03:31) mhu: Hmm, I think a user cannot change a "shared" item? But otherwise, user modifyable setting of course take precedence over the "template" / installed values; is it this that you are asking?
(17:06:12) LiHeng: As i saw, Path-Options have two layers if user edit a item , it will keep in user cache. And take back the original setting while user click "default" button.
(17:06:59) mhu: yes, that's how PathOptions work.
(17:08:13) LiHeng: so original (default) setting are kinds of "Shared" , but it can be changed by a user
(17:08:14) mhu: but that is only a "default" value of an item that could be stored in the merged users directory as well as the users modified setting, I think.
(17:08:48) mhu: yes, the "default" settings come from the shared layer.
(17:10:06) mhu: this is what I would call a "template", where for every (new) users first startup the user settings are generated and stored in the users directory (as you are planning)
(17:11:56) mhu: sorry, but looking at the time, do have more to discuss for today?
(17:11:57) LiHeng: oh, i see, shared item wouldn't be modified by user any time
(17:12:15) mhu: yes, that's the idea :-)
(17:13:07) LiHeng: oh, we need talk about, therefore we come back this discussion next work, right?
(17:13:35) mhu: okay, yes we can continue this discussion next week, of course.
(17:14:28) LiHeng: before it, we should confirm serveral preblom in this week,:)
(17:14:38) mhu: yes, okay
(17:14:46) LiHeng: thank you,
(17:15:11) mhu: thank you for your fresh ideas for an old problem.
(17:15:46) LiHeng: thank you for your patience. see you next Thurday
(17:15:53) mhu: okay, bye all, see you next week.
(17:15:55) xiuzhi: see you
(17:16:05) LiHeng: sorry thursday
(17:16:07) mhu: bye
(17:16:13) LiHeng: bye
(17:16:16) liangjun: mhu: bye
(17:17:08) LiHeng: liangjun:can you confirm "finalized" setting?
(17:20:19) LiHeng: 88
(17:20:31) liangjun: bye
