|About this template|
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000 and the Community ??
Time: 15:57– 16:34
(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
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Time: 15:57– 16:56
(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
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Time: 15:53– 17:27
(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