Performance/Meetings/2009 03

Brief meeting summary

Agenda

1.Update overall status

2.To Discuss how to measure performance of user experience.

Overall Status

Work	Status Description	Member(IRC nick)
benchmark-system	Established on the server, and applying static IP and permission to publish benchmark-system on Website.	LiHeng
Reorder code to reduce file I/O	I finished an early prototype which can trace function calls during start up. It writes trace files that a second tool uses with the module map file to create a linker order file. For a first test I instrumented and traced some libraries and the results look promising. The page fault rate for the Writer library could be reduced by 40% (125 instead of 210) and that's also the time we win(866ms instead of 1378ms) on cold start up. Other libraries show less good results. More information can be found on the wiki: http://wiki.services.openoffice.org/wiki/Performance/Reorder_Symbols_For_Libraries	oo_cd
CWS asynloadingimpress	I have update my code in CWS about Asynchronous Loading today, named "asynloadingimpress" ,I fix the code base on m42, and I re-update my code today	Zhangyuwei
CWS sb107	Moved my CWS sb107 to DEV300m44, where Hamburg now uses a Linux tool chain similar to the new one I had experimented with. Numbers with the Hamburg tool chain look almost as good as mine (will see if even newer tool chain has even better results). Biggest win time-wise appears to be using the GNU-style symbol hash tables, though, a feature that can now be enabled on those new tool chains.	sb
Refactoring Calc area broadcaster	Resumed work on refactoring Calc area broadcaster.	erAck
Tool Comparison of ODF documents	I have developed a tool that allows to compare ODF documents. Its based on JUnit and therefore runs in Java. I'm currently cleaning it up and will provide the source code next week.The purpose of this tool is to implement regression tests when we optimize load/save	odf-mib
CWS mhu17 module 'store' optimization	cws mhu17 (module 'store' optimization) finally integrated into dev300 m45; in parallel, evaluating buffered file I/O for inclusion into sal / osl file handling functions; also, setting up new cws for further module 'store' optimization (rdb filesize reduction).	Matthias
	Redesign AL(in sw/sd) according to the new OO3 code base. Symphony will be end of August 2009 and be OOo 3 based.	ycheng1
CWS downscaledimageshow	I have put a test-code in CWS named "downscaledimageshow " which can use the downscaled bitmap only to draw or "slide show" on the screen. In this code, the temp scaled threshold is 1000*1000 pixels which will be set by the user selection.	Jackiesun

Details

IRC meeting time

To change time of IRC meeting to Fridays, 08:00am UTC

Action Items:

Liheng put up test-system code to SVN

benchmark-system/src/benchmark for native helper code

benchmark-system/src/tools for view & trace tools 

Log of meeting

(4:32:47 PM) liheng: Agenda:

(4:32:47 PM) liheng: 1.Update overall status

(4:32:47 PM) liheng: 2.To Discuss how to measure performance of user experience.

(4:33:17 PM) liheng: I have established benchmark-system on the server, and applying static IP and permission to publish benchmark-system on internet.

(4:33:17 PM) liheng: I will finish a manual of usage for this first version in a week.

(4:33:19 PM) xiuzhi: Dieter_: moin

(4:35:30 PM) tora-japan [n=user@p1219-ipbf506hodogaya.kanagawa.ocn.ne.jp] entered the room.

(4:36:48 PM) Malte: liheng: Sound good :) Is the code in SVN?

(4:38:41 PM) liheng: Malte:also next week, my company need a test report before because code and system will be published on internet :)

(4:39:43 PM) cd_oo: I finished an early prototype which can trace function calls during start up. It writes trace files that a second tool uses with the module map file to create a linker order file. For a first test I instrumented and traced some libraries and the results look promising. The page fault rate for the Writer library could be reduced by 40% (125 instead of 210) and that's also the time we win...

(4:39:45 PM) cd_oo: ...(866ms instead of 1378ms) on cold start up. Other libraries show less good results. More information can be found on the wiki:http://wiki.services.openoffice.org/wiki/Performance/Reorder_Symbols_For_Libraries

(4:39:53 PM) Malte: liheng: I don't see a reason not to put siurces in SVN before going public

(4:40:58 PM) Malte: I would like somebody to setup a similar system here too, to get a better understanding

(4:41:29 PM) odf-mib: Yes, this does make sense. Also to avoid duplicate efforts.

(4:42:25 PM) liheng: Okay,I will send code next monday

(4:42:50 PM) Malte: Great :)

(4:43:05 PM) ycheng1: cd_oo: interesting. I also tried this method on oo1.1 code base and can get about 8% improvement on rebased dlls.

(4:43:38 PM) zhangyuwei: I have update my code in CWS about Asynchronous Loading today, named "asynloadingimpress"

(4:44:34 PM) cd_oo: ycheng1: This is not related to rebase (precalculate relocations for a specific load address). I reorder symbols to have better locality and therefore less page faults.

(4:44:36 PM) odf-mib: zhangyuwei: I've noticed that the tinderbox builds show errors for the CWS

(4:46:28 PM) ycheng1: cd_oo: yes, I see, the function reorder to reudce page faults. What I mean is if the dlls are not rebased, then OS will help to relocation them and read them into memory sequentially, which will eliminate the function reorder effect

(4:47:05 PM) ycheng1: cd_oo: I modified that sws tools to do this

(4:48:18 PM) tora-japan: My status: I have been studying memory allocation in UNIX, especially in Solaris, and one of the its objects - finding hard-to-reproduce-hard-to-find-its-suspicious-module bugs - is undergoing. And then hopefully, the next generation of OUString would be discussed in a few week, which might use more practical, purpose-specific memory allocation system.

(4:48:19 PM) cd_oo: ycheng1: Ok, we rebase all OpenOffice.org libraries which is done in the postprocess project. I couldn't see any relocations by the OS during start up.

(4:48:19 PM) sb: my status: Moved my CWS sb107 to DEV300m44, where Hamburg now uses a Linux tool chain similar to the new one I had experimented with. Numbers with the Hamburg tool chain look almost as good as mine (will see if even newer tool chain has even better results). Biggest win time-wise appears to be using the GNU-style symbol hash tables, though, a feature that can now be enabled on those new...

(4:48:22 PM) sb: ...tool chains.

(4:48:51 PM) liheng: Malte:I will put source in benchmark-system/src/benchmark for native helper code and benchmark-system/src/tools for external tools in Java

(4:48:54 PM) zhangyuwei: odf-mib: I fix the code base on m42, and I re-update my code today

(4:49:05 PM) ycheng1: cd_oo: we can discuss it more detail in the mail list.:)

(4:49:34 PM) erAck: my status: resumed work on refactoring Calc area broadcaster.

(4:50:13 PM) ycheng1: my status : redesign AL(in sw/sd) according to the new OO3 code base.

(4:50:15 PM) odf-mib: my status: I have developed a tool that allows to compare ODF documents. Its based on JUnit and therefore runs in Java. I'm currently cleaning it up and will provide the source code next week.

(4:50:44 PM) odf-mib: my status2: The purpose of this tool is to implement regression tests when we optimize load/save

(4:50:45 PM) ycheng1: And there will be several people in Symphony working on this, the initial target day should be before the end of August, 2009.

(4:51:37 PM) liheng: odf-mib:Why to compare ODF documents?

(4:51:41 PM) ycheng1: AL(asynchronous loading)

(4:52:08 PM) Matthias: status: cws mhu17 (module 'store' optimization) finally integrated into dev300 m45; in parallel, evaluating buffered file I/O for inclusion into sal / osl file handling functions; also, setting up new cws for further module 'store' optimization (rdb filesize reduction).

(4:52:19 PM) Jackiesun: my status: I have put a test-code in CWS named "downscaledimageshow " which can use the downscaled bitmap only to draw or "slide show" on the screen. In this code, the temp scaled threshold is 1000*1000 pixels which will be set by the user selection.

(4:52:27 PM) odf-mib: liheng: When we make optimization to the load and save code we have to make sure that what we save with the optimization equals what we have saved before.

(4:52:43 PM) liheng: ycheng1:redesign? You mean refactoring?

(4:53:36 PM) ycheng1: liheng: yes, there are too many change between oo1.1 and oo3.x

(4:53:38 PM) zhangyuwei: odf-mid: I test the code on windows, can build and run

(4:54:21 PM) Malte: ycheng1: This means Symphony end of August 2009 will be OOo 3 based?

(4:54:44 PM) ycheng1: malte:Yes

(4:54:50 PM) Malte: Cool :)

(4:54:55 PM) tora-japan: mhu: sounds nice! do you think it could be used for other module such as PDF export in vcl?

(4:55:13 PM) liheng: odf-mib:I think you mean that tool is for save changed parts?

(4:55:14 PM) zhangyuwei: ycheng1:ChengYuan, Thank you for your advice about AL. :)

(4:55:36 PM) Matthias: tora-japan: yes, but lets have a separate talk about your and my ideas; maybe via email ?

(4:55:47 PM) tora-japan: Sure!

(4:55:48 PM) ycheng1: malte : Sorry, not for normal release of Symphony, only beta

(4:55:57 PM) Malte: At least a start ;)

(4:56:02 PM) ycheng1: yes

(4:56:05 PM) ycheng1: :-D

(4:56:23 PM) Matthias: tora-japan: I'll contact you sometime within the next days.

(4:57:28 PM) odf-mib: liheng: The tools is just a comparison tool for ODF documents. It does not improve the performance in OOo. But it can help to ensure the quality of performance improvements.

(4:57:39 PM) tora-japan: mhu: thank you!

(4:58:05 PM) ycheng1: Before normal contibute back to oo3, we can put the AL code of oo1.1 on svn firstly and quickly

(4:58:30 PM) Malte: ycheng1: For what should that help?

(4:58:50 PM) Malte: And - how should it work?

(4:59:21 PM) liheng: odf-mib:I see, for measuring document in ODF

(4:59:23 PM) ycheng1: malte: for everyone to see the code and give some advice. We Symphony team still need much work to make it work in oo3

(4:59:46 PM) zhangyuwei: odf-mid: It can run, but there is a problem: It running slowing on m42.

(5:00:13 PM) Malte: ycheng1: But that code would be on OOo SD repository, not in performance module, so you can't put old stuff there.

(5:00:23 PM) liangjun [n=zenglj_@218.249.75.106] entered the room.

(5:00:34 PM) Malte: And dumping a copy of OOo 1.1 code in performance module doesn't sound like a good idea...

(5:01:14 PM) Malte: Then better describe your changes and ideas in the Wiki...

(5:01:26 PM) ycheng1: malte: you are right, then we can find other way to share the code. we can dicuss it by mail?

(5:01:42 PM) ycheng1: Yes

(5:01:43 PM) Malte: email == mailing list: yes

(5:01:46 PM) erAck: ycheng1: why not just make a tarball available?

(5:02:24 PM) erAck: nobody would want to merge code from 1.1 to 3.x anyway..

(5:02:24 PM) ycheng1: erAck: a tarball inclduing the changed source code ?

(5:02:32 PM) Malte: erAck: Also not a good solution.

(5:02:37 PM) Malte: Would need to be in SVN then.

(5:02:39 PM) erAck: Malte: why not?

(5:02:49 PM) Malte: We can't discuss code we download from some other location.

(5:02:56 PM) erAck: true.

(5:02:57 PM) Malte: Must be SVN, or mailing lists, or OOo Wiki

(5:02:59 PM) erAck: sigh..

(5:04:17 PM) ycheng1: yuwei : u'r welcome, the problem resolved?

(5:05:21 PM) zhangyuwei: ycheng1: yup. resolved ;)

(5:07:43 PM) liheng: It seems all status is here,we go next

(5:08:08 PM) liheng: 2.To Discuss how to measure performance of user experience.

(5:08:25 PM) liheng: Performance project will improve performance of OOo in 2 directions.

(5:08:25 PM) liheng: One is the technical improvement, like algorithm,refactoring, and so on,

(5:08:25 PM) liheng: the other is within scope of user experience.For technical improvement,

(5:08:25 PM) liheng: we can measure differences of our work easily, but in user experience

(5:08:25 PM) liheng: how to get the performance value of user's feeling is questionably.

(5:09:48 PM) Malte: If it is about async loading, it might help to have a notification when loading is completed

(5:09:55 PM) ycheng1: I suggest to compose some benchmark files firstly

(5:11:22 PM) ycheng1: e.g. big_plain_text.odt, big_complex_objects.odt, small_plain_text.odt, which will reflect the normal content and complexcity that user faced daily

(5:11:23 PM) liheng: Malte:Yes,but for saving it is difficult problem for us

(5:12:44 PM) Malte: Saving is the same - isn't it?

(5:12:59 PM) Malte: On mark when user can start working again, other when saving completed

(5:13:03 PM) ycheng1: then define some most-used operations such as load/save/close/startup/insert pic/...

(5:13:51 PM) Malte: first mark is for saving in background - not for partial saving

(5:14:22 PM) ycheng1: and assign different weight on each of operations, e.g. saving is more frequent than loading

(5:14:58 PM) liheng: Malte:Maybe yes, but how to remind user that they can do something again? ;)

(5:15:08 PM) ycheng1: finally can got one total benchmark score of each build

(5:15:33 PM) Malte: They don't haver to be reminded - they still expect that they can seamlessly continue working

(5:15:41 PM) liheng: ycheng1:We just build a benchmark system for that

(5:16:54 PM) ycheng1: sounds good, we may need to carefully select the benchmark files and operations to really reflect the user's feeling

(5:18:26 PM) tora-japan: Measuring some figures would be one of the ideas. Another idea might be to try to follow what ordinal users think. e.g. If a user wants to see solely some values on the first sheet in a Calc document file with a plenty amount of sheet, just do it. load the sheet and leave other sheet unloaded at the beginning, and continue to load the rest in background.

(5:19:15 PM) erAck: tora-japan: that's the long term goal I work on.

(5:19:42 PM) tora-japan: erArk: Ja (Yes)

(5:19:49 PM) liheng: Malte:QA of redoffice wait the progress bar complete, and they still can't do anything:(

(5:20:25 PM) Malte: liheng: yes - but that would change with storing in the background

(5:20:59 PM) erAck: btw, on Sunday Germany switches to daylight saving time, will we continue having the meeting at 8:30 UTC?

(5:21:07 PM) liheng: Malte:Yes,but some UI item is necessary:)

(5:21:12 PM) erAck: or should we switch to 8:00 UTC == 10:00 CEST == 16:00 CMT to accommodate the Chinese colleagues?

(5:22:17 PM) ***peter13j seconds erAck

(5:22:38 PM) liheng: and we must measure the point when UI item complete

(5:22:59 PM) liheng: arAck:Thank you,

(5:23:01 PM) liheng: +1

(5:23:03 PM) ycheng1: both time is ok for me:)

(5:23:12 PM) ***Matthias seconds erAck proposal also

(5:23:28 PM) cd_oo: +1

(5:23:31 PM) yugq: +1

(5:24:00 PM) liheng: okay, I will change the wiki page :)

(5:24:49 PM) ycheng1: malte: do you have plan to do 'storing in the background' and how? In my opinion, it's hard to do that because of the everywhere 'SolarMutex', unless in different process?

(5:25:15 PM) liheng: Who will take the minutes for this week?

(5:25:47 PM) Malte: ycheng1: We should consider removing solar mutex, making use of new threading framework

(5:25:57 PM) Malte: Then would also would need to quickyl clone documents in memory

(5:27:42 PM) lihen1: Malte:We can only clone changed parts

(5:28:04 PM) ycheng1: yugq: yes, a workaround is to keep using Application::reschedule to make UI smooth?

(5:28:05 PM) Malte: liheng: That would probably be more complicated, but an option...

(5:28:57 PM) yugq: ycheng: I think incremental save is a good idea, but hard to port to OO either. I'm trying some demo now.

(5:29:04 PM) lihen1: I try to analyze it

(5:29:43 PM) ycheng1: yugq: yes, the file format of ODF don't natively support the incremental saving

(5:29:51 PM) lihen1: Time up, I take the minutes for this meeting