Performance/Meetings/2008 03

From Apache OpenOffice Wiki
< Performance‎ | Meetings
Revision as of 07:51, 25 August 2009 by Penny (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Performance/Meetings/2008/03/27

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


Date: 2008/03/27
Time: 16:24– 17:29
Meeting No.:


Agenda:

(16:24:09) LiHeng: hi
(16:28:17) LiHeng: where is zenglj?
(16:30:04) mhu: Hi all
(16:30:19) LiHeng: hello
(16:30:36) LiHeng: how about your holiday?
(16:31:19) yugq: mhu, hi.
(16:31:52) mhu: oh, thanks. that was a good time.
(16:32:30) mhu: hi, yugq.
(16:32:31) LiHeng: mhu:we have some trouble with network , so zenglj would login later, we go first!
(16:32:45) mhu: LiHeng: okay.
(16:32:51) LiHeng: mhu:did you receive the Agenda?
(16:33:10) mhu: yes, I've read the agenda; looks okay.
(16:34:47) LiHeng: from this week, we start to do someting factly for performance optimizting
(16:36:12) LiHeng: Today , We start from "Optimizing in XML I/O, to improve config and document loading"
(16:36:42) liangjun: Hello every body. sorry.
(16:37:22) mhu: okay, sounds like a valuable task to start.
(16:38:08) LiHeng: mhu: we think that configmgr have some mainly problems , XML I/O is one of those
(16:38:40) mhu: yes, as we said last time: configmgr is a good place to optimize.
(16:38:46) LiHeng: so, we want to optimizing XML Process and improve config load
(16:40:04) LiHeng: mhu:yes , and you say other team just working in configmgr , so we want to improve XML I/O
(16:40:51) yugq: There are some "heap manage" process in configmgr, and it seems they consume a lot of call time from the profile.
(16:41:24) mhu: ah good; but you could also look and and see, what others are actually doing (and if anything is actually done).
(16:42:13) mhu: yugq: yes, that is what I think someone has already looked into... wait a second, I try to find something...
(16:43:46) LiHeng: we are making a proposal on ConfigMgr and XML I/O , and that we will send to you and SB . so we can discuss them in mailing list
(16:44:06) xiuzhi: sorry I am too late as the traffic jam
(16:44:35) yugq: xiuzhi: hi!
(16:44:35) LiHeng: xiuzhi: It is Beijing's traffic, alway jam
(16:44:46) mhu: yugq: on the "Performance" wiki page, under "Work List and Progress" there is mentioned a "configrefactor01" cws; this might be the work that once was started to simplify the configmgr code.
(16:44:52) xiuzhi: yugh: :)
(16:44:55) mhu: yiuzhi: hi
(16:45:02) xiuzhi: LiHeng :)
(16:45:09) xiuzhi: mhu::)
(16:45:17) LiHeng: ;)
(16:45:26) yugq: mhu: Thanks! I'll check it.
(16:45:40) mhu: s/yiuzhi/xiuzhi/
(16:45:51) mhu: :-)
(16:47:01) LiHeng: mhu:do you think we can make an independent module to process XML I/O
(16:47:06) mhu: LiHeng: okay, yes a proposal would be good; and yes, SB and I would surely be right to read that proposal.
(16:47:41) mhu: LiHeng: I think there are already some independent modules to process xml...
(16:49:07) mhu: there is a "stoc/..." module for xml document handler (based on expat), and there is a "unoxml" or so module, based on libxml, ...and so on.
(16:49:41) liangjun: The oo currentry configmgr use the sax component .It's right?
(16:49:48) LiHeng: mhu: oh, I just want to make sure ,that any function that process XML is indenpendent, is not?
(16:50:06) mhu: yes, I think they use the sax component from the stoc module.
(16:50:12) yugq: All use sax to parse I think.
(16:50:45) mhu: yes and no, some part (dont know which) uses DOM from unoxml.
(16:51:07) yugq: And every kind of XML should have a paser implementation.
(16:51:10) mhu: but yes, most use sax.
(16:51:24) LiHeng: liangjun:The SAX wourld not be made cache for deal some problem , so we also need DOM support
(16:52:02) LiHeng: s/wourld/would
(16:52:59) liangjun: LiHeng:I think it only parser.and cache the result .
(16:54:22) liangjun: LiHeng:I think it only parser once .and cache the result as tree struct.
(16:54:55) LiHeng: liangjun: not caching ALL, only needed
(16:56:36) LiHeng: so , if we have module that deal with SAX and DOM, we can make performance well
(16:56:51) LiHeng: xiuzhi:do you think so?
(16:57:52) LiHeng: and if we make a well XML module , document load/save will fine too, one stone two bird;)
(16:58:42) mhu: I think, a good (xml) base implementation is only one part; the code that uses this base implementation can still make silly things (e.g. call a million times instead of a thousand times).
(16:59:06) xiuzhi: Liheng:agreed
(16:59:44) liangjun: LiHeng: It possible has two manager, one for currently using reslut ; one for currently not using result ;:)
(17:00:15) yugq: mhu: agree!
(17:00:36) LiHeng: mhu:yes, so i think we must improve DOM, and developers can deal some complex problem with only one cache
(17:01:36) yugq: LiHeng: I think we can deal with different XMLs with different parsers.
(17:02:05) yugq: LiHeng: But to document, I think sax is better.
(17:02:14) LiHeng: yes , it the second topic ,today ;)
(17:02:35) mhu: are we really sure where the problem with xml parsing actually is; is it the basic xml parser code, or is it the code that uses the parser ?
(17:02:43) yugq: Because document file sometimes is not "tiny" one, but "huge".
(17:03:45) mhu: I also think that a sax implementation is the basic part to get right.
(17:03:47) yugq: mhu: Yes. To find out what really cause problem is most important.
(17:03:50) LiHeng: yugh: yes, for "huge" some data can be parsed on needed only
(17:05:19) LiHeng: mhu: On sax base, we must process all data from Config or document, but some data will be not used
(17:07:05) LiHeng: mhu: for a huge configuration or document, we can't build a mapping cache for all data , and parsing parts that to be needed
(17:08:01) yugq: LiHeng: maybe we can find out what really cause problem and try your idea.
(17:08:29) mhu: okay, understood. you think of an efficient caching mechanism. I leave that to you to come up with good ideas here.
(17:09:02) LiHeng: and provide DOM interface on cache , if any function need that part , they can access it by those interface
(17:09:04) LiHeng: :)
(17:09:07) LiHeng: Yes
(17:09:44) xiuzhi: +1 caching mechanism
(17:10:10) LiHeng: mhu, we can discuss more details in mailinglist , for caching mechanism :)
(17:10:29) mhu: if you need test cases for "huge" documents, try spreadsheets; they can easily be made several hundred megabytes of xml to parse.
(17:10:55) liangjun: LiHeng: and about OO currently implement ?
(17:11:00) LiHeng: mhu: thank for your tip, we just need it
(17:11:26) LiHeng: liangjun: what do you means?
(17:11:47) LiHeng: how about OO implement XML now ?
(17:12:07) mhu: you could ask Niklas Nebel (spreadsheet project lead; xiuzhi should perhaps know him) for test documents.
(17:12:16) liangjun: LiHeng:how about OO implement caching now ?
(17:12:45) LiHeng: most using sax , no caching,
(17:13:18) LiHeng: and DOM parse all tags and build memory structure,
(17:13:33) mhu: liangjun: there is almost no caching. for documents, all is directly converted via sax into document model objects (in module xmloff).
(17:14:52) LiHeng: ok, can we going into next?
(17:14:59) mhu: yes.
(17:15:03) yugq: yes
(17:15:10) LiHeng: 2.discuss about loading-time of configuration
(17:15:36) xiuzhi: mhu:yes. Niklas is expert on this spreadsheet, we can discuss it with him and erAck
(17:16:19) mhu: xiuzhi: so, you also know Eike; good.
(17:16:42) LiHeng: but i don't know him
(17:17:02) LiHeng: so , xiuzhi ,please introduce me to him ;)
(17:18:07) xiuzhi: LiHeng: no problem.
(17:18:30) LiHeng: mhu: the time of config-loading is a big problem to startup
(17:18:44) xiuzhi: LiHeng: mailinglist is a good place to discuss this
(17:19:19) LiHeng: okay, today we have little time now:(
(17:19:22) xiuzhi: and we can invite them attend this meeting if necessory,
(17:19:45) LiHeng: xiuzhi: ok
(17:20:53) LiHeng: mhu: we must find more and more configuration that is not nesseary on startup
(17:21:10) yugq: LiHeng: I think config itself is complicate, they are several layers and every layer must be parsed and merge together.
(17:21:39) mhu: okay, configmgr: yes, I think we already agreed that this is the best place to start.
(17:22:18) mhu: and yes, also look at silly usage of configmgr, i.e. things loaded at startup that are not needed.
(17:22:43) mhu: ...or thing loaded multiple times, like setup.xcu (?)
(17:23:21) LiHeng: mhu:it's a detail for config, that a lots of configurations in OO, and most load on startup. so we must make a list that desc necessary items for startup
(17:23:24) liangjun: LiHeng: use more thread do it.
(17:23:48) mhu: ...and yes, configmgr is (overly) complicated; please try to find out what has been done / planned with cws "configmgrrefactor01" (or so).
(17:24:07) yugq: mhu: OK.
(17:24:18) LiHeng: mhu: thank you
(17:24:46) mhu: ...that is "configrefactor01" as mentioned in wiki.
(17:25:50) mhu: ...and if that work was not finished, it is probably worth that you look and try to finish that.
(17:26:25) LiHeng: mhu: time is out, so i will send a timetable to discuss the recently works
(17:26:52) mhu: okay, yes please send that via email.
(17:27:22) LiHeng: okay,
(17:27:32) LiHeng: xiuzhi: do you have more?
(17:27:45) xiuzhi: LiHeng:no
(17:28:00) xiuzhi: IMHO,we can close the meeting now
(17:28:06) LiHeng: okay,
(17:28:51) LiHeng: that all'
(17:29:06) liangjun: :)
(17:29:07) xiuzhi: bye all
(17:29:08) LiHeng: bye
(17:29:13) liangjun: bye
(17:29:21) mhu: bye all, see you next week.


Go back

Personal tools