Performance/Meetings/2009 07
|
|
|---|
|
Quick Navigation Team Communication Activities |
| About this template |
Contents
Performance/Meetings/2009 07/31
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2009/07/31
Time: 15:58– 17:06
Meeting No.:
Agenda:
(4:00:57 PM) liheng: Hi,all
(4:01:29 PM) cd_oo: Hi all :-)
(4:02:36 PM) cl: g'day
(4:02:56 PM) Dieter__: Hi all :-)
(4:03:16 PM) Dieter__: Hi Liheng :-)
(4:03:56 PM) liheng: Dieter_:Hi Dieter!:)
(4:04:15 PM) erAck_away is now known as erAck
(4:04:41 PM) erAck: good morning / afternoon
(4:05:25 PM) Matthias: Hi all
(4:06:13 PM) liangjun: :) Hi all
(4:06:20 PM) ***Matthias wonders whether the meeting has already started
(4:08:18 PM) erAck: mhu: not really, loose gathering ;)
(4:08:39 PM) Matthias: erAck: ah, someone is awake :-)
(4:09:18 PM) erAck: nearly ...
(4:09:34 PM) liheng: cl:Are you Christian Lippka?
(4:09:51 PM) cl: liheng: yes
(4:10:05 PM) liheng: cl: :),Thank you,for you attend this meeting.
(4:11:21 PM) liheng: Let's update our status.
(4:13:17 PM) ***Matthias is still working on buffered file I/O (only part-time, thus more slowly than expected myself); still refactoring the windows implementation.
(4:13:44 PM) cd_oo left the room (quit: Read error: 104 (Connection reset by peer)).
(4:14:12 PM) sb: My status is that I am still busy with the configmgr rewrite. Functionality is stabilizing now (though still quite a number of features missing), and I will concentrate on a first round of performance improvements of the new code now.
(4:15:54 PM) liheng: Yuguoqiang has a training today, His status:Setup SVN and m29 m44 source code on the OOoBenchmarkSystem for Diagram information view.
(4:16:57 PM) cd_oo: My state: I stopped my work on restructuring svtools. I have to move and change too many files in the project and we want to change from Subversion to Mercurial for OOo 3.2. In the end this work is too dangerous to be integrated short before code/feature freeze. Therefore I want to do this work for OOo 3.3. The first results look very promising: ~800k for the startup part of svtools and 2.6...
(4:16:57 PM) cd_oo: ...MB for the load on call part. Currently we load both libraries ~3,5 MB on start up.
(4:19:23 PM) liangjun: My state: Continue odf document load performance :)
(4:20:27 PM) liheng: My status:Work on the auto-test for OOoBenchmarkSystem.
(4:24:13 PM) liheng: I will make the manual for OOoBenchmarkSystem. And put the raw-data and report of OOo3.1 and m44 on it in public area in two week.
(4:25:20 PM) liheng: Let's start to discuss about optimizing of XML-based format processing
(4:27:41 PM) cd_oo left the room (quit: Read error: 104 (Connection reset by peer)).
(4:29:17 PM) liheng: cl:We discussed optimizing of XML-based format processing and the lazy processing
(4:29:46 PM) liangjun: liheng: cl: http://blogs.sun.com/GullFOSS/entry/xml_performance_and_now_for is Christian Lippka's blog.
(4:30:05 PM) liangjun: http://wiki.services.openoffice.org/wiki/Performance/Odf_document_load_performance_increase_feasibility_analysis/Implement is our implement.
(4:30:58 PM) liheng: liangjun:
(4:31:22 PM) liheng: liangjun: Thank you!
(4:31:36 PM) liangjun: liheng: :P
(4:32:27 PM) cl: so how is your implementation going?
(4:33:33 PM) liangjun: cl: We plan reimplenent the "xmloff"
(4:34:58 PM) cl: great
(4:35:13 PM) liangjun: of course, use currently OO's source. split every element's process
(4:35:29 PM) liangjun: into some steps.
(4:35:48 PM) cl: I don't see where the performance gain will come from, what am I missing?
(4:35:59 PM) liheng: cl: To parse xml fastly, and make sure which content we have to process at first, and to process certain objects with multi-thread
(4:36:21 PM) liangjun: liheng: :)
(4:36:36 PM) cl: O I understand, sorry that I proved that this will not work :-)
(4:37:40 PM) liangjun: And processSubContexts(): Sub elements process, It has three solutions to process :P
(4:38:21 PM) liheng: Why? I think it can work at least in large document
(4:38:50 PM) liangjun: liheng: yes ,
(4:39:30 PM) liangjun: It is my one method :)
(4:40:05 PM) cl: large documents would not matter if you constantly call into openoffice core for the reasons I outlined in my blog
(4:40:35 PM) cl: and if you decouple xml parsing from filling the ooo core you will find it is only a small fraction of the time needed, therfore no gain from multi threading
(4:40:42 PM) odf-mib: liheng,liangjun,cl: I think we are talking about two different solution regarding what is done by the individual threads.
(4:40:44 PM) cl: but you still can try and prove me wrong :-)
(4:41:13 PM) liangjun: odf-mib: yes
(4:41:26 PM) odf-mib: cl: In your solution, the XML processing was done in one thread, the remainder of the import in another one.
(4:42:09 PM) odf-mib: liangjun: I think what you are suggesting is to divide the import of the pared data into the application models into multiple threads.
(4:42:23 PM) odf-mib: pared->parsed
(4:43:22 PM) liheng: cl: We scan XML at first time in order to decide which part we must process, so we can reduce the time of calling into openoffice core
(4:44:26 PM) cl: for partial document loading?
(4:44:41 PM) liangjun: odf-mib: :) . yes I split the sub element' process into multiple threads.
(4:45:31 PM) liangjun: liheng: It is very good idea
(4:45:32 PM) liheng: cl: Loading whole document but processing partial document
(4:46:08 PM) cl: liheng: I don't understand, load the whole document but processing only partial? How to load a whole document without procesing whole xml stream?
(4:46:53 PM) liheng: cl: I means parse all XML stream ...
(4:47:23 PM) cl: ok
(4:47:38 PM) liheng: ... but do real processing when the objects need be rendering
(4:48:37 PM) cl: do you plan to store the parsed xml data in memory or do you plan to re parse the document multiple times?
(4:49:06 PM) liangjun: cl: in memory
(4:49:26 PM) cl: ok
(4:49:27 PM) liheng: maybe only a index of it
(4:50:19 PM) liangjun: liheng: cl: yes , we can get element by index
(4:50:38 PM) cl: so that is basicly a dom tree
(4:51:16 PM) liheng: yes, a dom tree is must
(4:51:28 PM) cl: so I tried that
(4:51:47 PM) cl: but for partial loading it may work but I would not suggest reusing xmloff to much
(4:52:36 PM) liangjun: I use this struct store element data
(4:52:39 PM) liangjun: struct State
(4:52:39 PM) liangjun: {
(4:52:39 PM) liangjun: rtl_uString* mp_elementName;
(4:52:39 PM) liangjun: xml::sax::XAttributeList* mp_attributes;
(4:52:39 PM) liangjun: rtl_uString* mp_elementContent;
(4:52:40 PM) liangjun: sal_uInt32 m_local;
(4:52:41 PM) liangjun: sal_uInt32 m_distance;
(4:52:43 PM) liangjun: sal_uInt32 m_count;
(4:52:45 PM) liangjun: };
(4:53:29 PM) liangjun: so we can access every element by index.
(4:53:56 PM) odf-mib: Where are the elements themselves stored?
(4:54:38 PM) cl: you should take a look at the fast sax parser to get rid of the string for the element name
(4:55:17 PM) liangjun: odf-mib: now I use a vector
(4:56:39 PM) liangjun: cl: In my implement, I use an enum for element name and attribute name.
(4:58:01 PM) cl: liangjun: great!
(4:58:34 PM) liangjun: of course the name space
(4:58:49 PM) liangjun: cl: :)
(5:01:56 PM) liangjun: now I'm implementing the impress.
(5:01:57 PM) liheng: cl:If you have some progress please tell us in mailing list
(5:03:23 PM) liangjun: liheng: cl: :P
(5:03:52 PM) liheng: Okay,time up
(5:05:34 PM) liheng: cl:Tkank you again.:)
(5:05:35 PM) liangjun: :)
(5:06:25 PM) liheng: Bye all, and have nice weekend.
(5:06:36 PM) odf-mib: Bye, have a nice weekend
(5:06:41 PM) odf-mib left the room.
(5:06:41 PM) liangjun: bye
Performance/Meetings/2009 07/24
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2009/07/24
Time: 16:00– 17:13
Meeting No.:
Agenda:
(4:00:41 PM) arwe: Hi all :-)
(4:01:02 PM) odf-mib: H1
(4:01:07 PM) odf-mib: Hi!
(4:01:08 PM) cd_oo: Hi all :-)
(4:01:15 PM) liheng: Hi,Good morning / afternoon!
(4:02:00 PM) yugq: hi all
(4:02:42 PM) liangjun: :P hello all
(4:04:49 PM) liheng: First: Any status needs be updated?
(4:05:33 PM) Matthias: Hi all ...
(4:05:56 PM) Matthias: ... I guess, I am late again
(4:06:14 PM) arwe: I am working on diverse chart optimisations regarding the DrawingLayer side (see CWS aw075...)
(4:07:05 PM) liheng: Matthias:No we are just beginning:)
(4:07:18 PM) Matthias: liheng: fine, thanks
(4:07:27 PM) liheng: arwe is the 1st update
(4:08:14 PM) erAck_away is now known as erAck
(4:08:52 PM) erAck: moin, late today..
(4:09:12 PM) cd_oo: My state: I am working on optimizing libraries, currently svtools. I want to split the library into a part which is needed on startup and another one which can be loaded on demand.
(4:09:47 PM) liheng: My status: To deploy SVN server and OOo src on benchmark-system for diagram review and maintion, and establish the autotest system for them.
(4:11:41 PM) ***Matthias did spend his time recovering a cws from disk crash after power fail, thanks to zfs raid config nothing was lost, but took more time than planned
(4:11:59 PM) yugq: my status: Most of the benchmark system web site is finished.
(4:12:11 PM) liangjun: My state: odf document load performance :-(
(4:13:07 PM) liheng: cd_oo: I think the svtools is split into several libs, do you need to combine them first?
(4:14:46 PM) cd_oo: liheng: Yes, there are some UNO services which can remain in separate libraries. I want combine the object files of svt and svl so we have only one lib which is loaded on start up.
(4:15:59 PM) Matthias: cd_oo: please keep rsvl
(4:16:04 PM) Matthias: ...
(4:16:08 PM) Matthias: sorry ...
(4:16:55 PM) Matthias: cd_oo: please keep the resulting svl free from vcl dependencies, ucb et al may still depend on svl, or not ?
(4:17:59 PM) liheng: odf-mib:After yugp closed the work of benchmark-system web, I want to put your RTL_LOG tools in benchmark-system and that all developer can upload their logs and get sheet documents,how do you feel about it?
(4:18:16 PM) cd_oo: mhu: Are you sure that ucb needs svtools? I have just looked into the prj folder and there is no dependency to svtools.
(4:18:42 PM) cd_oo: mhu: uc ucb : cppuhelper CURL:curl OPENSSL:openssl NEON:neon LIBXML2:libxml2 offapi sal salhelper ucbhelper udkapi comphelper NULL
(4:18:47 PM) ***Matthias does not remember exactly who nowadays depends on svl but not vcl ... no I am not sure
(4:19:21 PM) cd_oo: mhu: I will check if svl (without vcl dependency) is really needed nowadays.
(4:20:22 PM) odf-mib: liheng: That would be oky for me.
(4:20:47 PM) Matthias: cd_oo: I am not talking about "module" dependenices but "runtime" dependencies; a dependency on "module svtools" does not say whether a a runtime dependency to svt or svl or both exists
(4:21:20 PM) Matthias: cd_oo: thanks for looking into it, anyway
(4:22:59 PM) liheng: odf-mib:We will encapsulate your code in servlet, if we get some trouble, we will send mail to you
(4:23:27 PM) odf-mib: liheng: okay
(4:24:08 PM) sb_: hi all, sorry for being late
(4:25:06 PM) liheng: Hi,sb_,nothing for sorry, you sent the email to us;)
(4:27:37 PM) liheng: If we have no more status to be updated, we go to next topic "Discuss about optimizing of XML-based format processing"
(4:29:38 PM) liheng: For long time many persons have been analyzing XML processing in OOo individually, ...
(4:34:15 PM) liangjun: :) http://blogs.sun.com/GullFOSS/entry/xml_performance_and_now_for is Christian Lippka's blog.
(4:35:45 PM) liangjun: http://wiki.services.openoffice.org/wiki/Performance/Odf_document_load_performance_increase_feasibility_analysis/Implement is my implement.
(4:37:50 PM) liheng: and mostly focus on to process XML-based format document async or to parse data in use, but it is a huge work, I think we need discuss and work together.
(4:38:51 PM) liangjun: However, the realization of my stay on paper only. It has no result now. ;-)
(4:42:01 PM) liangjun: http://wiki.services.openoffice.org/wiki/XML_Load
(4:42:56 PM) liangjun: http://wiki.services.openoffice.org/wiki/Calc/Performance/Saving_Sheets_Separately
(4:43:14 PM) odf-mib: Christian isn't here today. Maybe we should invite him to one of our next meetings.
(4:44:04 PM) liheng: For we are facing that the document is change to large and large and OOXML will be also a mainly format, so performance of XML-based document loading is a significant problem for us.
(4:44:53 PM) liheng: odf-mib: Okay,I will invite him next week.
(4:46:57 PM) odf-mib: liheng: Is loading/saving ODF really slower than OOXML?
(4:49:20 PM) liheng: odf-mib:Not now, I think, OOXML is a filter
(4:51:07 PM) liheng: But, in the future we must face these two format at the same level, for use, they do not careful the ext-name of a document :)
(4:52:55 PM) erAck: we might care about loading MOOXML, but only after loading/saving ODF; saving to MOOXML is on the very low end, IMHO.
(4:56:06 PM) odf-mib: I'm a little bit confused. Are we talking about performance of loading ODF, or of loading OOXML, or both?
(4:57:27 PM) liheng: I think both
(4:59:03 PM) liheng: OOo must support both well
(4:59:14 PM) Matthias: well, I guess ODF has higher priority here, even more so as Christians (?) blog shows that the pure XML parsing is only a small fraction (3%)
(4:59:48 PM) Matthias: ...and most of the time is spent in processing, not in the XML parser
(5:01:17 PM) liheng: Matthias: XML parsing only is small but lazy parsing is a large part
(5:01:35 PM) liangjun: mhu: :) yes, I agree it.
(5:02:09 PM) Matthias: liheng: I am not sure I understand ?
(5:02:24 PM) Matthias: liangjun: :-)
(5:02:45 PM) Matthias: liheng: can you explain ?
(5:02:47 PM) odf-mib: We must differ between parsing and processing. What you mean is probably lazy processing.
(5:03:37 PM) liheng: odf-mib:Yes processing :)
(5:04:18 PM) Matthias: ah okay, that explains it :-)
(5:05:30 PM) liheng: Matthias: I means we only need to cache some data but not create real document-object at first, if they do not need to display
(5:07:04 PM) liheng: oh, times up
(5:07:15 PM) yugq: mhu: agree with XML parseing has a small fraction. I think more and more people think of the asynchronous load method or lazy load and that need the suitable parse method like the pull parse -- Christian think of this way.
(5:08:16 PM) liheng: I will invite Christian next week, we continue this discussion next week.
(5:08:24 PM) Matthias: yugq: yes, of course. Christians experiments / prototyping is exactly the right thing to explore.
(5:09:21 PM) yugq: mhu: so, I think we still need to talk about the parser, if there is any idea about the load.:)
(5:10:39 PM) Matthias: yugq: if you so want, yes. I simply think the parser is only secondary (independent of how you parse, speed comes from other concepts)
(5:11:01 PM) liheng: yugq: All maybe from the parser ,but where we can save the time is the point ;)
(5:11:38 PM) liheng: Matthias: :)
(5:11:43 PM) Matthias: :-)
(5:12:01 PM) yugq: sorry for not watch the time:P
(5:12:19 PM) Matthias: ...and that other concept may then suggest the best method to parse.
(5:12:39 PM) Matthias: yes, time is up for me as well ...
(5:13:03 PM) liheng: Okay, that's all, see you all next week, and nice weekend!
Performance/Meetings/2009 07/17
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2009/07/17
Time: 14:42– 16:49
Meeting No.:
Agenda:
(15:42:54) yugq change the topic: Please update your status!
(16:02:16) arwe: Hi all :-)
(16:02:25) yugq: hi all:)
(16:03:14) yugq: Please update your status.
(16:03:14) yugq: Liheng and other guys in Beijing are taking part in some training now.
(16:03:14) yugq: liangjun's status: working on CWS configtune01 to handle the package and install problem.
(16:07:31) erAck: morning
(16:08:33) cd_oo: cd's status: Had to make fixes for MinGW port for CWS fwk112. Therefore integration into master is delayed. I want to start with optimizations next week looking to consolidate our libraries. Especially to only have code/data in startup libs that is needed on startup, other code/data should be moved out.
(16:08:37) arwe: I was working on some common performance stuff regarding rendering, especially fat lines (lines with a LineWidth) and charts where 10000th of that lines are used.
(16:09:10) ***erAck has no status update, working on oasis odf
(16:09:12) arwe: Fat lines and MetaFile recording has been optimized. Also Fat line geometry creation
(16:09:40) arwe: I will also look for chart performance regarding rendering and MetaFile stuff
(16:14:03) arwe: Especially with the new AntiAliasing it is pretty hard to get the same performance as before (which is achieved in most cases); people simply do not want to accept that AA costs time at all.
Performance/Meetings/2009 07/10
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2009/07/10
Time: 16:01– 16:56
Meeting No.:
Agenda:
(4:01:09 PM) liheng: Hi,all
(4:01:32 PM) cd_oo: hi all :-)
(4:02:38 PM) yugq: hi all
(4:03:14 PM) liheng: Good morning / afternoon! :)
(4:04:03 PM) liheng: Let's update our status.
(4:04:57 PM) liangjun: hello all.:)
(4:07:30 PM) erAck: good morning /afternoon
(4:08:31 PM) liheng: My status:Arrange check-points of performance diagram for comparing 3.0, 3.1 and 3.2 in OOoBenchmarkSystem, and build script and testcases.
(4:09:44 PM) cd_oo: My status: CWS fwk108 (Writer optimizations regarding language files) has been integrated into DEV300m52. CWS fwk112 (non-rebased libraries) has some problems with two build bot systems (Ubuntu 8.04 AMD64 and MinGW), hopefully this can be fixed today. Currently I am busy with file picker issues and Windows 7 compatibility.
(4:09:54 PM) sb: My status is that I am still busy re-implementing a (fully functional, but not yet optimized) configmgr, as explained last week.
(4:11:14 PM) Matthias: Hi all, sorry for being late
(4:11:37 PM) liheng: Matthias: We are updating our status:)
(4:11:50 PM) Matthias: ah, okay...
(4:12:45 PM) liangjun: my status : continue odf document load performance :)
(4:12:50 PM) ***Matthias is still working on mhu20, specifically implementing buffered file IO for windows; unix (linux, solaris that is) can already be tested
(4:13:40 PM) liheng: sb:Your re-implementing work is for simple and distinct configmgr?
(4:15:51 PM) sb: liheng: What do you mean with "distinct configmgr"?
(4:17:12 PM) liheng: Matthias:I think cws mhu17 is also for optimizing IO ?
(4:18:29 PM) Matthias: yes, mhu17 was optimization of 'store' (basically cold start, memory consumption, instruction count), already integrated
(4:19:07 PM) liheng: sb:I think , clear or simple configmgr, easy to re-implement on optimizing
(4:20:26 PM) sb: liheng: Yes, exactly.
(4:20:49 PM) liheng: Matthias: Yuguoqiang and me just do some benchmark on it :)
(4:21:45 PM) liheng: sb:Do you have some solution in config data format?
(4:22:01 PM) liheng: sb: Do you have some solution in config data format?
(4:22:07 PM) Matthias: liheng: fine with me; can you somehow publish the results, please ?
(4:24:35 PM) liangjun: sb: I know the package script rarely.Our testing are manual configuration data. we can discuss with mail if you have any question.
(4:24:49 PM) liheng: We are launching OOoBenchmarkSystem on http://219.239.158.91:8080/OOoBenchmarkSystem/, and when we make out some report ,we will post them in Status Trace
(4:25:57 PM) sb: liheng: For now, I read in all the xcs/xcu files at startup, and write all modifications to a single XML file (with a format based on xcu format) in the user layer. Once the functionality is stable, I will experiment how best to optimize this (potentially even using something completely different in the end).
(4:29:00 PM) sb: liangjun: What do you mean with "package script"? And what do you mean with "our testing are manual configuration data"? Can I build CWS configtune01 and give the resulting OOo installation set a try, without any other things I would need to do? (Also, I wonder why the fresh setup of CWS configtune01 is based on rather old DEV300m41, instead of something current like DEV300m51.)
(4:35:50 PM) liangjun: sb: CWS configtune01 , our source code can compile. but it can't build a install packge. now we manual replace OOo's some files , and test our current code.
(4:35:54 PM) liheng: sb:liangjun means they do some works with to change the library and config-files manaully. And configtune01 is really has some trouble in get installation set, and other engineers are working for fix these problem.
(4:36:50 PM) liangjun: liheng: thanks :P
(4:38:14 PM) sb: liangjun: I see. So, I will wait with having a look until the experience will be smoother...
(4:42:14 PM) liheng: We need to put the tools that combine configfiles into one file into makefile and make installation well.
(4:43:38 PM) liangjun: liheng: yes, but ... :)
(4:44:41 PM) liangjun: I know little.
(4:46:36 PM) liheng: I can solve those problem, in a week:)
(4:47:16 PM) liangjun: :P
(4:51:41 PM) liheng: No more questions for me ;)
(4:52:21 PM) Matthias: liheng: did I miss something important at the beginning when I was not yet here ?
(4:52:48 PM) liangjun: sb: I'm sorry. :-(
(4:53:28 PM) sb: liangjun: Nothing to be sorry about. :)
(4:53:41 PM) liangjun: :P
(4:54:25 PM) liheng: Matthias: No, only some other status, and you can find them in wiki next week :)
(4:54:51 PM) Matthias: liheng: okay, thanks.
(4:55:33 PM) liheng: Okay, see you all next week!
(4:55:51 PM) Matthias: yes, have a nice weekend, bye all
(4:56:11 PM) liheng: Nice weekend! bye all.
(4:56:22 PM) erAck: bye all
(4:56:27 PM) Matthias left the room (quit: "good bye").
(4:56:35 PM) yugq: bye all
Performance/Meetings/2009 07/03
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2009/07/03
Time: 15:58– 17:01
Meeting No.:
Agenda:
(3:58:38 PM) The topic for #oooperformance is: Next meeting scheduled : ... please put the right date / hour ( CEST / UTC .. and so on )
(3:59:55 PM) arwe: Hi All!
(4:00:55 PM) yugq: hi all
(4:01:01 PM) cd_oo: Hi all :-)
(4:01:10 PM) liangjun: hi all :P
(4:04:54 PM) Matthias: Hi all
(4:06:21 PM) ***Matthias wonders whether the meeting has started already ?
(4:06:34 PM) sb: Anybody interested in getting this going? Liheng yesterday wrote that he would like to "discuss refactoring goals of configmgr".
(4:06:51 PM) sb: I can step in on that:
(4:07:07 PM) Matthias: yes, please go ahead, stephan
(4:07:52 PM) sb: I (finally ;) got to writing something in the Wiki (<http://wiki.services.openoffice.org/wiki/Performance/Configuration>) about what I am currently doing and what my motivations are:
(4:10:00 PM) sb: As I explained before, I see no other solution than to re-implement configmgr, to be able to then implement performance improvements, fix long-standing bugs, etc. So, in a way my work is rather different from the RedFlag work:
(4:11:24 PM) Malte: almost missed it ;)
(4:11:51 PM) liheng: Hi,all sorry I'm late
(4:11:57 PM) ***Matthias thinks sb's wiki summary of the configmgr problem(s) clearly hints to re-implementation
(4:12:06 PM) sb: They concentrate on specific performance improvements, while I (hope to) lay the foundations to implement any such improvements in a good way. I would be happy to see good ideas (if not code) from the RedFlag work make its way into the final new configmgr. (But still haven't seen working code from RedFlag, to see exactly what their work is, to experiment with it, etc.)
(4:12:33 PM) sb: .
(4:13:05 PM) sb: Hope this clarifies the situation. What do others (esp. the involved RedFlag people) think?
(4:13:25 PM) Matthias: sb: I think RedFlag's work fits into your second point (rearrange to improve performance)
(4:13:40 PM) Matthias: (or is supposed to fit)
(4:15:04 PM) Matthias: also: what we discussed some (long) time ago, was simplyfication of the code / design together with simplification of files on disk
(4:16:03 PM) liangjun: sb: sorry , we had sent some codes on cws. and we will update this code later
(4:16:17 PM) sb: mhu: yes, sure, exactly. The only issue I see is that any diff they produce against current configmgr will not apply to new configmgr, so their work is somewhat wasted.
(4:16:46 PM) mba [n=mba@nat/sun/x-7aabbe3bad493b4b] entered the room.
(4:16:50 PM) sb: liangjun: can you give me a ping once there is code there that I should have a look at? Thank.
(4:17:11 PM) Matthias: sb: I knew what you meant :-) yes, right, you should somehow coordinate, and if you are faster ...
(4:18:04 PM) liangjun: sb: ok .
(4:18:13 PM) Matthias: ...that is why we are having these discussions, to try not to waste each others time with too much overlapping implementations ...
(4:18:36 PM) sb: My rough time estimates are to have something working (w/o any performance improvements) in about a month, then start improvements. (But those estimates are still rather vague.)
(4:18:38 PM) Matthias: ... and to agree what is important enough that we throw some people on it
(4:19:54 PM) Matthias: I think "about a month" is a perfectly valid estimate (and actually fast)
(4:19:55 PM) liangjun: I think we can send our currently code on cws, :P
(4:20:56 PM) yugq: mhu: about the configuration related api, i think the config item path is quite like some kind of XPath, is it an old fashion solution or there are other cosiderations? (and also the hierachy structure). I think simplify the api is a good idea.
(4:21:05 PM) liangjun: next week . and tell you on maillist
(4:21:38 PM) Matthias: yugq: yes, see sb's third point in the wiki (and also the recent email discussion)
(4:21:59 PM) sb: liangjun: Thanks.
(4:22:34 PM) Matthias: ...so, yes, at some point in time we should probably also think about simplifying the api
(4:23:06 PM) liangjun: sb: you are welcome :)
(4:23:41 PM) sb: yugq,mhu: Yes, lets proceed in steps. Simplifying the API (and simplifying the code using the configmgr) is probably a rather huge step, but will probably eventually become necessary.
(4:23:43 PM) Malte: sb: What about meeks comments with wrt some API not / almost not needed?
(4:24:12 PM) Malte: avoid that from the beginning?
(4:24:45 PM) liangjun: mhu: sb: yes , It is very good idea
(4:24:47 PM) ***Matthias still agrees to sb's three step proposal on the above mentioned wiki page
(4:25:17 PM) sb: Malte: I am currently implementing all the interfaces, but do not flesh out the functions that are never called (startup, smoketest, those are the things I am currently testing). What never gets called will stay in that nonfunctional way for now.
(4:25:32 PM) Malte: OK :)
(4:29:19 PM) yugq: mhu, sb: yes. I think a light weight configuration framwork is needed. When we're looking into configmgr in OOo, we find the structure is so complicate. So some times i wonder the old structure if need so much complicate indeed or not. I think many problems comes from these kind of complication. But we can't find a another configuration data definition way.
(4:30:44 PM) Matthias: yugq: this is sb's first step: cleanup and simplify the code, that it can better be changed in future
(4:31:02 PM) Matthias: s/code, that/code, so that/
(4:32:05 PM) Matthias: ...including, even further simplifying it.
(4:34:03 PM) sb: yugq: I do not see that the current UNO API per se has that bad consequences on the way the configuration data can be defined/stored. The complex UNO API probably has consequences on the complexity of the current configmgr implementation, which in turn has consequences on being easily able to modify the data storage thing in the current implementation.
(4:37:29 PM) yugq: sb: Ok, maybe api changes, the implementation can be simple also. :)
(4:38:46 PM) sb: yugq: I hope to have everything simple in the end, data format, implementation, API. :)
(4:39:39 PM) yugq: My status: I'm maintained the benchmark system web site this week. It enables register user now. And the further function will be put on soon later.
(4:39:49 PM) liheng: Yes, data format is basic for the others
(4:40:14 PM) liheng: URL: http://219.239.158.91:8080/OOoBenchmarkSystem/ , We add user register so that you can save you benchmark rawdata and results of analysis for multi-version and comparison in the futher
(4:40:16 PM) yugq: sb: yes, perfect goal!
(4:40:32 PM) yugq: liangjun: data is basic, format, i think not.
(4:40:51 PM) yugq: liheng:data is basic, format, i think not.:)
(4:42:29 PM) liheng: I means to make data format as simple as possible is basic for simplify implement and API it's not?
(4:45:22 PM) yugq: liheng: yes, i think so. I misunderstood you :P.
(4:45:34 PM) sb: liheng: Remember, a simple implementation is not and end in itself. What counts is that we ultimately improve performance, most probably via better data file format/usage. The final implementation should then be as simple as possible given the constraints imposed by the performance requirements.
(4:46:15 PM) sb: ...but I think we all mean the same thing, just express it differently. ;)
(4:46:54 PM) liheng: sb: Yes, ;)
(4:46:56 PM) ***Matthias thinks so too ... many different words for almost the same thing :-)
(4:47:10 PM) yugq: :-D
(4:48:45 PM) liheng: In our early works we only combining all data in one file
(4:51:19 PM) sb: liheng: And maybe that already can give enough of a performance boost? All shared data in one file, all per-user data in another, merging just those two at runtime?
(4:51:49 PM) Matthias: that was the idea, at least
(4:52:56 PM) yugq: sb: no, every user has a copy, so no merging at runtime. Thus the security is a big argument.
(4:53:09 PM) liheng: the prototype benchmark result in wiki http://wiki.services.openoffice.org/wiki/Configmgr_Refactoring/test_result_2009_02_19
(4:53:42 PM) sb: yugq: Yes, so my idea is to do it slightly differently (as I just described), and see whether that gives good enough performance.
(4:55:08 PM) liheng: sb:I think it not enough performance so that we are going on :)
(4:55:53 PM) sb: liheng: I see. Lets see where we are going, then. :)
(4:56:52 PM) liheng: I think data format is first
(5:00:44 PM) liheng: Ok, time up
(5:01:00 PM) liheng: Bye and see you next week
