Difference between revisions of "Performance/Meetings/2008 04"

Latest revision as of 23:13, 17 March 2010

Performance/Meetings/2008/04/24

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000 and the Community ??
Performance Project

Date: 2008/04/24
Time: 15:57– 16:34
Meeting No.:

Agenda:

(15:57:02) LiHeng: please check mail:)
(15:57:26) LiHeng: i forgot to forward to you
(15:58:39) liangjun: oh. I don't receive it .
(15:59:15) LiHeng: again:)
(16:00:44) mhu: Hi all.
(16:01:00) liangjun: mhu: Hello
(16:01:12) LiHeng: hi,mhu
(16:02:37) LiHeng: mhu:because we are just designing the new Configmgr so we have a few topics to discuss
(16:02:50) kuangliang: hi,mhu
(16:03:04) LiHeng: mhu:did you receive the "weekly report"?
(16:03:12) mhu: Yes, I have received your weekly report. Looks god. Thanks.
(16:03:35) mhu: s/god/good/
(16:03:38) LiHeng: ;)
(16:03:42) mhu: :-)
(16:04:28) LiHeng: i have 2 small tipocs, do you have more?
(16:05:41) mhu: No, nothing more.
(16:06:15) LiHeng: ok , let's start with "Naming CWS for our ConfigMgr improving"
(16:06:45) mhu: Except, maybe, I have read that you received from Malte the CWS performance test code (?)
(16:07:25) mhu: So, are you now able to perform these tests yourself ?
(16:07:35) LiHeng: no code , test case and data only
(16:08:08) mhu: ah, okay. Do those test cases and data help ?
(16:08:12) LiHeng: we are just try to run them on our CWS in Beijing
(16:08:21) mhu: okay, good.
(16:08:57) mhu: that' all I had.
(16:09:13) LiHeng: In second tipoc we want to discuss some about tools set;)
(16:09:23) mhu: okay...
(16:09:54) LiHeng: mhu:we want to create new CWS after 5-1 holiday
(16:10:26) mhu: okay
(16:10:37) LiHeng: so, please you name it , our first CWS
(16:11:10) mhu: oh really? Give me a few seconds....
(16:11:40) LiHeng: a CWS for impove Configmgr :)
(16:11:54) mhu: oh yes, that's what I thought.
(16:12:42) mhu: so, maybe something with "configmgr" and "tuning" in it?
(16:13:21) mhu: or maybe "configcache" ?
(16:13:26) mhu: or ... ?
(16:14:08) LiHeng: "configcachetuning" maybe so long
(16:14:14) mhu: maybe we can also include your ideas for a name ?
(16:14:49) yug1: configtuning
(16:15:46) mhu: yes, "configtuning" sounds fine for me; maybe add "01" ?
(16:16:08) mhu: maybe, you do more CWS for configmgr ?
(16:16:42) LiHeng: maybe we start from "00" , C style ;)
(16:16:53) mhu: :-)
(16:17:00) yug1: :-D
(16:17:19) mhu: I am still thinking FORTRAN, I guess :-)
(16:17:32) liangjun: :)
(16:18:16) mhu: yes, "configtuning" is general enough to cover almost all changes that you want to apply to configmgr.
(16:18:51) LiHeng: ok, CWS "configtuining00" will be opening soon for Combine Cache files and make a dynamic index :)
(16:20:05) LiHeng: now , 2 Define tools set for OO evaluation.
(16:21:32) LiHeng: For a long time, we think about collection a set of tools for OO evaluation like Malte give us,
(16:21:55) LiHeng: and document manaul for them
(16:23:20) LiHeng: and that let anyone who interest in performance of OO can be start easily
(16:24:05) LiHeng: mhu:do you think OO.o need it?
(16:25:34) mhu: sorry, I needed to answer a local question; now I'm back again...
(16:26:35) mhu: so, performance tests and documentation needed? yes, it think it would be used, if people know about it and can understand how to use it.
(16:26:36) LiHeng: mhu:that maybe a chain of tools depoly , getting raw data , anlysis to report
(16:27:20) mhu: yes, that's probably a chain of tools, you are right.
(16:28:44) LiHeng: now, we only use profile tools, and some tools like Malte give us or Andrew published,
(16:29:16) LiHeng: do you have some experience
(16:29:17) LiHeng: ?
(16:29:39) mhu: hmmm...
(16:30:40) LiHeng: i want to develop a tool with ODF and OO too view raw data and compare in more viewpoint
(16:30:42) mhu: for real code analysis, I think there is nothing better, than what you already know how to use; these tools (like valgrind) produce the data, and you analyze it (manually).
(16:32:15) mhu: for automated measurement of performance characteristics (like startup time), the tooling that Malte provided is one way to measure and detect systematic differences (automated).
(16:33:32) mhu: data like those that Andrew (Z (?)) published, mostly cannot be reproduced, as it is ususally not known how they where produced; usually you need to re-do those experiments yourself (manually)
(16:34:31) LiHeng: as making raw data ,we can't do more now ,but we can create some analysis and report system to storage raw data and compare them

Performance/Meetings/2008/04/17

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

Date: 2008/04/17
Time: 15:57– 16:56
Meeting No.:

Agenda:

(15:57:58) LiHeng: :-)
(15:58:02) LiHeng: ;)
(16:04:29) LiHeng: we are ready:)
(16:05:17) yugq: :)
(16:05:29) liangjun: :)we are not receive the mail ?
(16:06:54) LiHeng: which mail? cws test or matthias?
(16:08:46) liangjun: today subject
(16:09:30) LiHeng: hi mhu!
(16:09:32) mhu: Hi all, sorry for being late; got stuck in the Hamburg morning traffic :-(
(16:10:20) LiHeng: Beijing is in same status, maybe more heavy than Hamburg:)
(16:10:47) LiHeng: Did you receive the mail from us, yesterday?
(16:11:57) mhu: From what I heard, Bejing traffice is indeed more heavy that in Hamburg.
(16:12:10) mhu: And yes, I've got your email yesterday.
(16:12:27) yugq: mhu:hello!
(16:12:39) mhu: I have not yet looked into the zip file, but only read your proposal.
(16:12:47) mhu: hi yugq
(16:13:04) liangjun: mhu:hello!
(16:13:45) mhu: hi liangjun
(16:13:56) kuangliang: mhu:hi
(16:14:02) mhu: hi kuangliang
(16:14:29) LiHeng: mhu:we check CWS Configrefractor01, and find michaels remove Heapmanager and impoving startup
(16:15:05) mhu: Yes, and did it improve startup ?
(16:16:14) LiHeng: but we are just proving that may not be effective for other time , load/save and ...
(16:16:52) LiHeng: mhu:yes, on debug version ,we testing , 2 seconds up
(16:16:53) mhu: LiHeng: I also received your email with attached zi file; so I don't need to download from your ftp server (hopefully).
(16:18:03) mhu: yes, that is no improvement for other xml related slowness; but good to hear that it improves things; in particular, the code should now be easier to change.
(16:19:30) LiHeng: mhu:yes , michael make code simpler , you can see it in we report
(16:21:00) LiHeng: mhu:and that, we discuss configmgr in 2.4.1 and want to improve it in other sides
(16:21:26) LiHeng: 1/Combine "Cache Data" to less files, and that reduce file I/O when searching in config
(16:21:30) LiHeng: 1.Combine "Cache Data" to less files, and that reduce file I/O when searching in config
(16:21:56) LiHeng: 2.Create dynamic index to cache some config-node in the every Component that usually needed
(16:22:31) mhu: @1) yes, a better combination of the cache files sounds like a good idea.
(16:23:10) LiHeng: we are just comparing configmgr beteewn 2.3.1 and 2.4
(16:24:30) LiHeng: we hope to make configmgr to be evaluated independently
(16:24:42) LiHeng: he is down
(16:24:43) LiHeng: :(
(16:25:06) liangjun: :)
(16:26:35) mhu: sorry, my gaim / pidgin just crashed... did I miss something in the last two minutes ?
(16:27:36) liangjun: (4:24:07 PM) mhu left the room (quit: Remote closed the connection).
(16:27:37) liangjun: (4:24:31 PM) LiHeng: we hope to make configmgr to be evaluated independently
(16:27:51) LiHeng: liangjun:thank you
(16:28:14) LiHeng: mhu:and that, we discuss configmgr in 2.4.1 and want to improve it in other sides
(16:28:34) LiHeng: we are just comparing configmgr beteewn 2.3.1 and 2.4
(16:28:43) LiHeng: we hope to make configmgr to be evaluated independently
(16:30:28) LiHeng: for example , if configure size larger and larger , we want to we can calculate speed of loading/initializing of configmgr
(16:31:12) mhu: okay, let me summarize what I understand...
(16:32:01) mhu: you want to improve configmgr separately from other (xml related) improvements
(16:32:30) LiHeng: yes;)
(16:32:39) mhu: then also improve xml loading saving for documents (and again also for configmgr).
(16:32:56) mhu: okay, thanks. Yes, I think that is a good plan.
(16:33:42) mhu: I also think, that the 2 points in your proposal are fine
(16:34:20) mhu: that is, (1) cache files and (2) cache nodes
(16:35:36) mhu: I think, what each application (e.g. writer) needs from config, is spread over multiple config files / nodes, so caching / reorganizing in memory makes sense, I think.
(16:36:11) LiHeng: Yes ,because Michael remove the HeapManager, when some config value use frequently, maybe have slowly process
(16:37:37) LiHeng: we are still in process to determine effect
(16:39:00) LiHeng: we have a idea, that cache node in Component level
(16:39:17) LiHeng: not only , base layer
(16:39:25) mhu: I think, some of this caching of nodes is also done in helper classes (in svtools ?) ConfigItem, and derived SvtXXXOptions classes.
(16:40:06) LiHeng: :)we have a idea, that cache node in Component level, ie in SW , SC, SD every module
(16:40:38) LiHeng: because , a lot of Config use by only one module
(16:41:54) LiHeng: and that we and estimate relatively index (key), and search in short path
(16:44:05) mhu: yes, I think that is a good idea; part of it looks similar to ConfigItem / SvtXXXOptions helper classes; you should probably look into these as well ( how they work and how they are used).
(16:44:58) LiHeng: okay, we will research that and make a report to you
(16:45:47) LiHeng: we can discuss again based that report :)
(16:47:17) LiHeng: and we can recompile the config to short keyname for private index format to improve memory using and searching-time
(16:47:42) mhu: okay, thanks. (here is a hopefully better hint, for example: svtools/source/config/pathoptions.cxx)
(16:48:13) mhu: and yes, your idea may be better than what is there now :-)
(16:48:47) LiHeng: we are just proving it
(16:50:33) LiHeng: By the way, from this week we will make a weekly report of Wiki, mailinglist, projects about performance improving and important point in IRC
(16:51:05) LiHeng: and send it to you every Tuesday
(16:52:49) LiHeng: if you want to discuss some topics please send mail to us , we and talk about it on IRC Thursday
(16:53:50) mhu: okay, that sounds good; and yes, I should respond more to your emails...
(16:54:32) mhu: I just read (in parallel to our discussion) your summary document (ConfigContrast.odt). Looks good.
(16:54:53) mhu: And no, otherwise I don't have more for today.
(16:55:05) LiHeng: no for me, others?
(16:55:15) yugq: no for me.
(16:55:19) mhu: I look into the cachegrind data sometime later (maybe tomorrow).
(16:55:37) kuangliang: no for me
(16:55:53) LiHeng: okay, see you next Thursday
(16:55:54) liangjun: no for me
(16:56:08) mhu: okay, see you Thursday. Bye all.
(16:56:12) LiHeng: Bye
(16:56:12) kuangliang: bye
(16:56:14) yugq: Bye.
(16:56:15) liangjun: bye

Performance/Meetings/2008/04/08

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

Date: 2008/04/08
Time: 15:53– 17:27
Meeting No.:

Agenda:

(15:53:49) yugq: mhu:hi!
(15:54:28) mhu: hi, yugq.
(16:21:34) LiHeng: hi, all
(16:21:53) kuangl: hi
(16:31:10) LiHeng: mhu:xiuzhi can't attend meeting today, he is participating in the meeting IDF (Intel Developer Forum '08)
(16:32:06) liangjun: hello
(16:34:06) mhu: Hi all.
(16:34:12) liangjun: :)
(16:34:13) LiHeng: mhu:xiuzhi can't attend meeting today, he is participating in the meeting IDF (Intel Developer Forum '08)
(16:34:56) mhu: LiHeng: Ah, yes. I've already heard of the IDF (which historically was in California).
(16:35:37) mhu: First, something procedural...
(16:36:17) mhu: In Germany there is now "daylight savings time", i.e. it's already one hour later than last week...
(16:36:56) mhu: Can I propose that we shift our meeting to 30min earlier? Would that help you also?
(16:37:18) LiHeng: yes , of cause
(16:37:58) mhu: okay, thanks. that helps avoiding conflicts with other meetings.
(16:38:21) LiHeng: "course" ,sorry
(16:38:48) LiHeng: on problem;)
(16:39:05) LiHeng: begin from agenda?
(16:39:15) mhu: yes, I'm ready to start
(16:39:34) LiHeng: 1.discuss about loading-time of configuration
(16:40:26) mhu: yes ?
(16:40:29) LiHeng: we need your some help to decide Novell working and its result
(16:40:43) yugq: mhu: Can we join in Michel Meeks' work and do something?
(16:40:51) mhu: okay, how can I help?
(16:41:58) mhu: Last time we talked about this "configrefactor01" CWS; is this what Novell did?
(16:41:59) LiHeng: mhu:yugq has review the change from Novell , but it has not more effective
(16:42:41) LiHeng: yugq:please,tell us what you think
(16:44:51) yugq: I saw what mhu mentioned last meeting about "configmgr" in wiki page. And their refactor trial seems not effective enough.
(16:45:41) yugq: Only less than one second achieve.
(16:46:22) mhu: yugq: "effective enough" meaning "no improvement in performance", or "code no easier to understand" ?
(16:46:46) mhu: okay, understood...
(16:46:54) yugq: I mean "no improvement in performance".
(16:46:57) yugq: :)
(16:47:33) LiHeng: now , improve one second on startup
(16:47:35) mhu: but I think, 1 second can already be a lot of time :-)
(16:48:02) yugq: Maybe.
(16:48:20) mhu: but, my main question would be: Is the code now easier to understand, and easier to change than it was before?
(16:49:40) LiHeng: Meeks is going to impove several change too.
(16:50:00) mhu: also, if the code is better to understand, and is also faster by one second, this is definitely a change that I would like to see integrated into the main codeline.
(16:50:32) mhu: LiHeng: what does Michael do, can you explain?
(16:50:49) yugq: They use berkeley DB instead of small XMLS, and have more unify interface I think.
(16:51:27) mhu: yeah, I dont want Berkeley DB; what is it about the interface?
(16:52:12) LiHeng: mhu: a few interfaces changed ,now
(16:53:06) mhu: are we talking about "configrefctor01" ?
(16:53:24) mhu: s/refctor/refactor/
(16:54:14) LiHeng: parts of it, and some other changes we want to put into OO:)
(16:56:51) yugq: mhu: I find a mail in OOo.org by Michel Meeks. He mentioned a "configmgr refactor" resolvent. I want to know if his resolvent been put into office now.
(16:57:02) yugq: http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=17932
(16:57:17) mhu: I just looked up "configrefactor01" in EIS: it has already been integrated into 680m238.
(16:57:46) mhu: ...that should be in OOo2.4, I think.
(16:59:00) LiHeng: mhu:yes, but we think configmgr would be simply more,
(17:00:15) mhu: LiHeng: "simply more," ?
(17:00:34) LiHeng: that can help to make the standard on code of all developers
(17:01:08) mhu: sorry, I'm not sure I understand what you are trying to say.
(17:01:32) mhu: ...can you say it again in other words, please?
(17:01:33) LiHeng: now, all modules use the registery and configmgr to get and set some values
(17:01:57) mhu: yes
(17:02:46) LiHeng: and format of configuration has changed serveral times, but
(17:03:17) mhu: yes
(17:03:51) LiHeng: some changes for process, and others for some reasons we don't know
(17:04:17) LiHeng: and that was unclarfiy for all developers
(17:05:04) mhu: configuration format changes?
(17:05:38) LiHeng: so , everyone build a map of configmge usage
(17:06:35) LiHeng: configure-format has been changed in some version 641 and later version
(17:07:29) mhu: the xml format has not changed, as far as I know; it has only been extended compatibly...
(17:07:55) mhu: but, 641 is hundred years ago :-) ( ooo 1.0)
(17:08:07) LiHeng: ;)
(17:08:55) LiHeng: but , some function build earlier than 641
(17:09:49) mhu: I'm very sorry, but I'm still not sure I understand what you are talking about; 641 is not relevant, I think.
(17:10:35) LiHeng: sorry too , for my english:)
(17:10:44) mhu: and yes, much code is 10 -- 15 years old.
(17:10:55) mhu: LiHeng: no, it's not your english...
(17:11:24) mhu: ...I don't know what you think, but I can hear what you say.
(17:11:46) LiHeng: i will send a mail ,that include some samples from us,
(17:12:07) yugq: LiHeng: maybe I need more discussion in Beijing.
(17:12:20) yugq: We need. Sorry.
(17:12:27) mhu: okay; I'm sure there are many places in configmgr that can be further improved.
(17:12:49) LiHeng: by the way, did you receive a email from me , that explain XML process improvement we want
(17:13:01) mhu: Please try to explain to me what you think; I really like to understand.
(17:13:24) mhu: Yes, sorry; I received the email, but didn't find time to answer.
(17:13:58) LiHeng: never mind,
(17:14:10) LiHeng: i just you know i want
(17:14:30) LiHeng: but , we are just making a proposal,
(17:14:34) mhu: and yes, I think your idea is good (lazy dom); maybe microsoft xml parser has similar functionality.
(17:15:19) LiHeng: becouse , some job from RedOffice i need more time to finish it
(17:15:56) LiHeng: YES MS parser has some features for lazy dom,
(17:15:56) mhu: same for me here: I also have another project that takes much of my time.
(17:16:36) LiHeng: i will take all time for Performance from next week
(17:16:54) LiHeng: :0
(17:16:57) LiHeng: :)
(17:17:10) mhu: that is good; I need to share my time between the two projects.
(17:18:04) LiHeng: okay, that all for first topic
(17:18:19) LiHeng: we do next shortly
(17:18:31) LiHeng: 2.Make a timetable for improvement in XML I/O
(17:19:35) LiHeng: i know OO3.o was freeze
(17:19:57) LiHeng: freezing
(17:20:30) LiHeng: So, i want to know what time 3.1 will freezing
(17:20:59) mhu: yes, according to http://wiki.services.openoffice.org/wiki/OOoRelease30 code freeze for 3.0beta is tomorrow.
(17:21:14) mhu: but I don't have a link for 3.1
(17:21:28) mhu: but...
(17:21:33) LiHeng: we need 3 or 4 months to improve XML
(17:21:58) yugq: http://wiki.services.openoffice.org/wiki/OOoRelease31
(17:22:02) mhu: that is code freeze for 3.0 beta only, not the final 3.0 release.
(17:23:00) mhu: aha, yes; thanks yugq, that link makes sense.
(17:23:08) LiHeng: so we want know which version we can change
(17:23:18) yugq: ;-)
(17:23:26) mhu: probably that is a good timetable, to target 3.1 then.
(17:24:09) LiHeng: yes, we can plan our feature now , thanks
(17:24:52) mhu: good.
(17:25:00) LiHeng: that all
(17:25:10) LiHeng: mhu: do you hava more
(17:25:11) LiHeng: ?
(17:25:14) mhu: I don't have more also
(17:25:42) LiHeng: yes i mail configuration sample next Monday
(17:25:51) mhu: then, 30min earlier from next week on?
(17:26:06) mhu: yes, please send me an email; I promise to answer :-)
(17:26:17) LiHeng: yes , 16:00 for beijing
(17:26:28) yugq: OK.
(17:26:29) mhu: 10:00 for hamburg
(17:26:35) LiHeng: ;)
(17:26:49) liangjun: :)
(17:26:49) LiHeng: bye
(17:26:56) mhu: okay, bye all
(17:26:56) liangjun: bye
(17:27:01) yugq: bye all.
(17:27:06) kuangl: bye

Go back