Performance/Meetings/2009 02

2009/02/05

#oooperformance

	[INFO]	Channel view for “#oooperformance” opened.
		YOU (odf-mib) have joined #oooperformance
	<xiuzhi>	liheng: Happy Niu Year
	<odf-mib>	Hello everyone!
	<frankloe>	Hi, all!
	<os_ooo>	Hi all!
		arwe (n=chatzill@c141103.adsl.hansenet.de) has joined #oooperformance
	<skotti>	Hi all
		Dieter_ (n=chatzill@192.18.8.1) has joined #oooperformance
	<Dieter_>	Hi all :-)
	<Dieter_>	Malte can't attend our IRC today
	<liheng>	xiuzhi:Happy Niu Year, ;)
	<liheng>	Hi,ALL
	<liheng>	we all here, other people can't back in office
	<liheng>	Dieter_:can we start?
	<Dieter_>	yes, please
	<arwe>	Hi all and thanks. Willsomeone moderate or will we all throw in what we want
	<skotti>	We have no agenda, afaik
	<skotti>	so it's more like throwing in i guess
	<Dieter_>	liheng is project owner and will moderate this IRC
	<liheng>	Dieter_:Some new persons in our meet, do you think we need a interduce ?
	<Dieter_>	yes, let's start with a brief introduction
	* skotti	: QA Engineer, Sun. Responsible for Automated testing of the framework component with current focus on test script performance
		_Nesshof_1 (n=_Nesshof@nat/sun/x-b56788764e68ee9c) has joined #oooperformance
		mhu (n=matthias@192.18.8.1) has joined #oooperformance
	<mhu>	Hi all, sorry for being late (traffice jam :-) )
	<liheng>	skotti:welcome :)
	<arwe>	Developer, responsible for DrawingLayer, working inter-applicationwide (always incompatible from svx...)
	* skotti	: I intend to do the performance measurements here at Sun
	<xiuzhi>	skotti:welcome
	<skotti>	xiuzhi: Thank you
	<os_ooo>	Hi, I'm Oliver Specht (os), working in the Writer team for ages and I'm now working especially on load/save performance issues.
	<xiuzhi>	os_ooo: Hi ,glad to see you here
	<liheng>	I'm LiHeng, from RedFlag 2000, worked on RedOffice(Based OOo) for 8 year, and also responsible for interoperability of RedOffice.
	* skotti	: My OOo nick is 'jsk' and my real name is Joerg Skottke but please call me Skotti
	<liheng>	os_ooo:Welcome :)
	<stephan_>	And I'm Stephan Bergmann (sb), working on startup performance (after working on other parts of OOo for years :)
		JackieSun (n=Jackiesu@218.249.75.106) has joined #oooperformance
	<Dieter_>	_Nesshof_1: Hi Martin, would you like to join the project?
	<_Nesshof_1>	Dieter_: I would like to offer my support as Program Manager, if wanted
	<liheng>	ALL:First I list some status of performance works in our side ...
	<xiuzhi>	_Nesshof_1: :)
	<Dieter_>	_Nesshof_1: yes, that's a good idea
	<liheng>	_Nesshof_1:Thank you, Martin.
	<liheng>	1.Refactoring Configmgr: Clear some superfluous objects for improving speed of startup. And it can reduce 2's in current version of RedOffice ...
	<liheng>	2.To collect test cases for measure OOo's performance
	<liheng>	3.And to design and implement some specail tools for measuring of OOo performance
	<liheng>	Last:To compare performance value between OOo and the other offices.
	<liheng>	These are mainly works we do in RedOffice
	<liheng>	And we are analyzing performance of Load/Save of ODF.
	<frankloe>	Good! Are these results already visible at the OOo wiki?
	<frankloe>	I am asking because the new project home page is now online: http://performance.openoffice.org
	<liheng>	Some of Refactoring Configmgr is on wiki page
	<liheng>	frankloe:Yes, I saw it, Thank you very mach.
	<stephan_>	To work on startup performance, I am currently breaking down overall startup into its parts, to see where time is going. Concentrating on Linux for now, using a combination of callgrind and strace to better estimate true wall clock time. Will start to put my findings into the wiki beginning of next week.
	<skotti>	So i gather our first focus is on startup performance?
	<mhu>	stephan_: Carsten Driesner is following a similar approach (on Windows, though); maybe, you could coordinate your work / findings ?
	<stephan_>	skotti: No, I think we work on different parts in parallel (startup, appl. load/save).
	<stephan_>	mhu: Yes, thanks for pointing it out. I will contact him.
	<mhu>	okay, thanks.
	<skotti>	I would then suggest that we bring some overhead into play from the start ;-)
	<mhu>	skotti: "overhead" ?
	<liheng>	stephan_:We make some benchmark code for measuring startup in realtime, not in debug state. I mail them with first test report in next week.
	<skotti>	mhu: Yep!
	<stephan_>	liheng: great, thanks
	<stephan_>	skotti: what do you mean?
	<skotti>	I would like to have it documented in Wiki which parts we're working on and who is responsible
	<skotti>	Goal being that we can see what progress the single parts are making
		zhangyuwei (n=zhangyw@218.249.75.106) has joined #oooperformance
	<mhu>	at least, we should document enough od our work, so that we dont loose oversight (who is doing what)
	<skotti>	If we have enough workforce to address several areas at the same time we might head into chaos otherwise
	<mhu>	skotti: I am also here to help avoid some of that chaos :-)
	* skotti	would have preferred a single threaded approach: One area at a time
	<skotti>	mhu: I know. But i have a very simple brain. ;-)
	<mhu>	:-)
	<odf-mib>	skotti: the web page and wiki are very new. We of cause plan to add documentation there. But that will take a few days.
	<frankloe>	If we have documented the current status of the project, we should announce the project officially to get some visibility on OOo and the press.
	<odf-mib>	frankloe: Yes, but let's have the documentation first.
	<odf-mib>	I think we are in the middle of a status check. Who's next?
	<skotti>	liheng: The list you posted: Which parts are planned, analysed and implemented?
	<frankloe>	odf-mib:Yes, the first impression always counts!
	<liheng>	frankloe:Yuguoqiang can help us to maintain Project page and WIKI page
	<zhangyuwei>	Excuse me, My name si Zhangyuwei, is a member of REDOffice2000. I'm working on loading/saving performance, and have done something about odf loading performance.
	<frankloe>	liheng:Sure!
	<xiuzhi>	zhangyuwei: you can discuss the issues with os_ooo. He focuses on load/save performance now
	<odf-mib>	xiuzhi: Several more people are working on load save performance, so please have any discussions on the mailing list
	<liheng>	frankloe:So, he will contact to you next week, and consult you :)
	<xiuzhi>	odf-mib: ok
	<mhu>	hi zhangyuwei, welcome.
	<liheng>	skotti:Yes,:) and create some specail tools
	<frankloe>	liheng:OK
	<liheng>	skotti: and we also make performance report for master builds
	<zhangyuwei>	os_ooo:I have done something about asynchronism loading file and imporved load performance.
	<odf-mib>	zhangyuwei: What did you do exactly?
	<os_ooo>	zhangyuwei: I want to make load/save process faster by changing the interfaces between xmloff and sw.
	<skotti>	liheng: Can i see the results of the performance reports? I've got something of that sort as well but i'm not at all happy with my approach
	<zhangyuwei>	I have finished asynchronism odp load
	<liheng>	skotti:Yes, I will publish them on project page or wiki
	<skotti>	liheng: Cool
	<mhu>	os_ooo: Oliver, similar to what SB said, could you start with improving the understanding of what exactly takes what time during loading documents ?
	<skotti>	liheng: I just applied for membership on the OOo performance pages, can you add me with a QA role
	<skotti>	?
	<os_ooo>	mhu: I will add some information to the wiki.
	<mhu>	os_ooo: okay, thanks.
	<liheng>	skotti:Sure
	<odf-mib>	All: I think we in general must provide more information on which area we are working, and must share results as soon as possible. Otherwise its difficult to coordinate things.
	<odf-mib>	zhangyuwei: In which CWS is the asynchronous load/save implemented.
	<arwe>	Good to hear that we will get some numbers; i would like to know which documents are used for measurements. Does anybody use documents form practice? I mean e.g. bugdocs from cases where users have reported that it is too slow?
	<zhangyuwei>	os_ooo:But I have some pr oblem about asynchronism load. slide sorter flush is monstrosity and slowly
	<arwe>	When we extract numbers from documents we make up ourselves, wnat willthe numbers represent (load/save of course, not startup)..?
	<liheng>	ALL:Sorry, we can focus on starpup and load performance, but, we must make sure for how to measure our works
	<skotti>	arwe: Yes and no. We can make up documents of our selves which include a defined feature set.
	<xiuzhi>	odf-mib: He did not create CWS until now .I will ask him to do that ASAP
	<arwe>	skotti: Do we have a collection of real world user documents with load/save performance issues?
	<zhangyuwei>	odf-mid: base on OOO3.0dev-m9
	<odf-mib>	arwe: Maybe we can have this discussion on the list?
	<skotti>	arwe: Yes, i think we have quite a repository. I'm taking this as action item for me: Find documents suited for performance measurement with bias towards real live scenarios
	<arwe>	skotti: Would it make sense to have a set of 'problematic' documents accessible over the Wiki-Page?
	<skotti>	arwe: I think so.
	<arwe>	skotti: If they are not confidential, please put them on the Wiki-pages.
	<skotti>	arwe: Yep.
	<liheng>	arwe:Yes we discuss it on the list, and we are collecting cases of performance now, but they are in Chinese
	<arwe>	Skotti: It will be interesting if the diverse measurements from diverse people will have comparable results with the same document set.
	<arwe>	This would be a good check if the measurements go in the correct direction...
	<skotti>	arwe: You won't get any dependable results unless you have a well defined test environment
	<skotti>	arwe: Or more correctly "comparable"
	<arwe>	skotti: Yes, but different measurements and methods should pont in the same direction when aplied to the same documents.
	<arwe>	skotti: Just a good test if the measurements give comparable results.
	<skotti>	arwe: Very likely
	<liheng>	ALL:I think we have a lot of things to do for peformance of OOo, but we can discuss them in list dev@performance.openoffice.org and select important things to disuss at IRC
	* mhu	thinks we could start with the idea that document load / save is generally a factor 10 too slow; then dependency on particular bugdoc documents becomes smaller ...
	<skotti>	liheng: +1
	<arwe>	skotti: I would be skeptical if my measurements with the same docs point in a completely different direction than someone else's...
	<skotti>	arwe: Yup, so would i
	<mhu>	liheng: yes, lets discuss most of this on the new mailing list.
	<skotti>	arwe: But i've seen it happen. Weird scenario, utterly unexpected
	<liheng>	ALL: So, I will post agenda of every IRC to mailing list, please you subscrib it ;)
	<liheng>	Time up, today,:) thank you and welcome to new Performance Project!
	<mhu>	liheng, xiuzhi: most of your teams are still not back from spring festival vacation ?
	<xiuzhi>	mhu: all of our members will be available next Monday
	<liheng>	Matthias:Someone has more vacation and someone can't get ticket:(
	<liheng>	But they will be back next week :)
	<mhu>	ah, okay; understood; hope the two of had some good time, though