Performance/Meetings/2009 03

Agenda of IRC

1.Update overall status

2.Continue to discuss how to organize the source tree in performance module and move all tooling code into it.

Overall Status

Work	Status Description	Member(IRC nick)
Tools with RTL_LOG	Have commited the tools that creates spreadsheet from RTL_LOG files and have updated its documentation ine the Wiki.	odf-mib
3.1 blockers	Was occupied with 3.1 blockers	erAck
OOo Performance Test System	Got the server machine and will deploy on it in next week , and post the performance diagram definitions for several hotspots on this server and wiki page.	liheng
Symbolic relocations	Further digging at -Bsymbolic-functions showed that using it is unsound, so looking at other ways (code modifications) to reduce number of symbolic relocations at startup. Interestingly, Hamburg RE switched to new GCC and binutils (somewhat older than what I use in my experiments) for DEV300m44, lets see whether my results are replicable with that toolchain too.	sb
PDF export	Try to do the I/O performance improvment around PDF export next week .	tora-japan
Asynchronous load	Have been fixing some bugs about Asynchronous Loading	zhangyuwei
Performance test	Implement simple application to test performance with I/O and muti-thread .	liangjun
Trace code for Windows	Due to show stopper I could only spend little time to work on the trace code for Windows. I finished the assembler part which is called by the MS compiler (_penter). Now I concentrate on the code which manages the calls and stores it for every module. Hope to have a version ready next week and try to get an order file for the Writer to optimize the linkage order.	cd_oo
Incremental save	Reserching on XML incremental save, trying to finish a demo now. I can finish it next week if it goes well.	yugq
Module "store" improvements	Cws mhu17 (module "store" improvements part 1) is being integrated, but maybe I need to deliver a late patch for building Windows.I am thinking about (a) store improvements part 2, and (b) buffered file I/O	mhu

Log of meeting

(4:36:27 PM) liheng: Agenda:1.Update overall status (4:36:28 PM) liheng: 2.Continue to discuss how to organize the source tree in performance module (4:36:28 PM) liheng: and move all tooling code into it. (4:37:48 PM) erAck: To start: nothing new from me, I was occupied with 3.1 blockers.(4:39:11 PM) odf-mib: I have commited the tools that creates spreadsheet from RTL_LOG files and have updated its documentation ine the Wiki.(4:39:39 PM) liheng: I got the server machine and will deploy benchmark-system service on it in next week. (4:39:39 PM) liheng: And we will post the performance diagram definitions for several hotspots refered by User Experience Index (Wiki Page:http://wiki.services.openoffice.org/wiki/UEI) on this server and wiki page(4:40:19 PM) Dieter_: liheng: that sounds really good!(4:40:29 PM) Malte: Yes :)(4:40:52 PM) Malte: wrt "how to organize the source tree in performance module "(4:41:00 PM) Malte: What about the place we discussed?(4:41:07 PM) sb: My status update: Further digging at -Bsymbolic-functions showed that using it is unsound, so looking at other ways (code modifications) to reduce number of symbolic relocations at startup. Interestingly, Hamburg RE switched to new GCC and binutils (somewhat older than what I use in my experiments) for DEV300m44, lets see whether my results are replicable with that toolchain too.(4:41:35 PM) liheng: Yes, but the waiting time is too tough.(4:42:06 PM) tora-japan: My status: Nothing new from me, either. (4:42:06 PM) tora-japan: I have been working for other things like how to run soffice.bin under 'chroot'ed environment, etc.(4:42:06 PM) tora-japan: I am trying to do the I/O performance improvment around PDF export next week.(4:42:32 PM) zhangyuwei: status: I have been fixing some bugs about Asynchronous Loading.(4:42:33 PM) liheng: Malte:about performance repository(4:42:52 PM) liangjun: I'm implementing simple application to test with I/O and muti-thread performance.(4:43:14 PM) liheng: eg.To move all performance tooling code into our repository(4:44:09 PM) cd_oo: Due to show stopper I could only spend little time to work on the trace code for Windows. I finished the assembler part which is called by the MS compiler (_penter). Now I concentrate on the code which manages the calls and stores it for every module. Hope to have a version ready next week and try to get an order file for the Writer to optimize the linkage order.(4:45:10 PM) yugq: My status: I'm reserching on XML incremental save, trying to finish a demo now. I can finish it next week if it goes well.(4:46:16 PM) Malte: liheng: odf-mib already has his tool in the repository, which is independent from your tool. (4:46:19 PM) Malte: What about your module "benchmark-system"?(4:46:38 PM) Malte: benchmark-system/src, benchmark-system/doc, benchmark-system/...(4:47:42 PM) zhangyuwei: odf-mid: hello, good afternoon, Have you checked my code about Asynchronous Loading on m42?(4:49:34 PM) odf-mib: zhangyuwei: Sory, no, I didn't. I may have overlooked something, but where do I find the code?(4:49:37 PM) liheng: These code will be posted in next week when server setup, maybe need a little changes.(4:49:49 PM) sb: Malte: Re agenda item 2: Last week, we wondered why there is a private SVN repo in performance.openoffice.org. Seems you at least know something about it?(4:51:20 PM) Malte: sb: No idea why it's a separate repossitory, but it's fine for me(4:51:25 PM) liheng: Malte:RTL_LOG was in sal/rtl module but I think we do same work, should be in the same module(4:51:41 PM) Malte: sb: It's also different in other ways:(4:52:00 PM) Malte: Web site is not in CVS, like rest of OOo, but in SVC, sub folder www(4:52:11 PM) Malte: SVC => SVN...(4:52:51 PM) Malte: liheng: Not sure what you mean, can you explain?(4:53:43 PM) odf-mib: To be clear: I did not change anything from RTL_LOG. I've only created a tool that analyzes the log files.(4:54:14 PM) odf-mib: The RTL_LOG file creates itself is part of OOo. We can't combine thes etwo things.(4:55:10 PM) sb: So we are all fine with using that additional repo instead of svn.services.openoffice.org/ooo/contrib/? (My guts say its odd that way, but I cannot think of any substantial arguments at the moment.)(4:55:48 PM) erAck: sb: no, I'm not fine with that. I don't see any benefit from using Collab's repository.(4:57:01 PM) erAck: au contraire, it might even complicate things because you need different access controls.(4:57:29 PM) erAck: plus, OOo will move to a DSCM.(4:57:59 PM) liheng: Malte:I mean we can move all performance tooling code into performance repository. (4:58:35 PM) mhu: Hi all, sorry for joining late ... (4:58:35 PM) zhangyuwei: odf-mid: "asynloadingimpress" in CWS. But, recently I fixed some bug, I'll update the code next week.(4:58:36 PM) Malte: linheng: We already do it. With tools - but you can't move RTL_LOG there.(4:59:25 PM) odf-mib: To be honest, what matters more to me is what we have in the repository, than where it is. In so far, it is okay for me to use the project's repository rather than the OOo repository.(4:59:49 PM) erAck: odf-mib: it will matter in future where the repository is.(5:01:11 PM) Malte: It will change anyway...(5:02:03 PM) odf-mib: erAck: It may, nut we can move the code later, if we like. I don't expect much code there actually.(5:02:07 PM) erAck: odf-mib: having it at Collab's SVN, you're alone when it comes to abandonig it. Having it at the regular OOo repository it will be nicely converted to the new DSCM by REs.(5:03:24 PM) liheng: In project's repository, anybody can be easy to find and reuse, it is my points(5:03:45 PM) Malte: liheng:yes(5:03:59 PM) odf-mib: liheng: +1(5:04:03 PM) Malte: erAck - that's an argument pro/contra Collab, but OOo is the wrong repository(5:04:14 PM) Malte: OOo should be OOo, not related tools(5:04:18 PM) liangjun: +1:)(5:04:59 PM) erAck: Malte: as Stephan already pointed out: a 'contributing' branch would separate it from the OOo code.(5:06:02 PM) Malte: We talk about "external" tools here, so I really don't understnad the issue, or I missed something(5:06:28 PM) erAck: and as I said already last time: Collab's SVN version is way old, if we'll run into problems, getting support from Collab is, well, you know, somewhat hard.(5:06:52 PM) Malte: That's a better argument ;)(5:06:54 PM) odf-mib: erAck: Maybe I'm wrong, but you would still copy all the content of contrib if you clone a repository although you never need that than only building OOo. So, its a waste of time, bandwidth and size.(5:08:27 PM) erAck: odf-mib: you don't touch svn.services.openoffice.org/ooo/contrib/ if you checkout or clone svn.services.openoffice.org/ooo/tags/(5:09:27 PM) Malte: erAck: We also think about moving extensions to their own repository. Should we stop this discussion until the other is solved?(5:11:09 PM) erAck: Malte: svn.services.openoffice.org/extensions/ and that's solved ... but maybe someone might think different.(5:12:27 PM) erAck: Malte: note that for extensions a separated repository (not just a branch) may be necessary for differenct access control.(5:12:51 PM) odf-mib: All: Does it really matter so much where the repository is. I think as long as those that actually contribute to the repository are fine with its location, then we should keep things as they are.(5:16:21 PM) liheng: Okay,we do all new tooling code and extenal tools in performance repository.(5:16:33 PM) erAck: odf-mib: I just see problems for the future using Collab's repo, so I want to prevent that.(5:18:07 PM) erAck: but as I seem to be the only one, go ahead ...(5:18:58 PM) erAck: you'll clean up later then ;-)(5:20:48 PM) liheng: Any more questions?(5:21:29 PM) liheng: Who can write the MM, this week?(5:21:45 PM) liangjun: LiHeng: I will make up and publish the MM of this meeting.(5:22:39 PM) mhu: LiHeng: anything important that I missed but should better know of ?(5:22:41 PM) liheng: thanks(5:22:56 PM) liheng: That all today(5:23:32 PM) liangjun: :)(5:23:49 PM) erAck: mhu: I don't think so, the minutes' log will have it ;)(5:24:04 PM) liheng: Matthias:Maybe the status of work(5:24:17 PM) mhu: thanks, Eike; I'll then read the minutes.(5:24:49 PM) mhu: LiHeng: you mean status of my work ?(5:24:59 PM) liheng: Yes,:)(5:25:53 PM) mhu: cws mhu17 (module "store" improvements part 1) is being integrated, but maybe I need to deliver a late patch for building Windows.(5:26:34 PM) liheng: Thank you, and the status of other works you can find in MM:)(5:26:34 PM) mhu: otherwise, I am thinking about (a) store improvements part 2, and (b) buffered file I/O(5:26:52 PM) mhu: ...and following all of your work :-)(5:27:07 PM) mhu: okay, then have a nice weekend(5:27:24 PM) liheng: Okay, bye