Performance Meetings templet
Performance/Meetings/2009/07/17
Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000
Performance Project
Date: 2009/07/17
Time: 16:27– 17:39
Meeting No.:
Agenda:
(4:27:35 PM) liheng: Malte:Hi!
(4:28:13 PM) odf-mib: Hello everyone
(4:28:18 PM) yugq: Hi all:-D
(4:29:36 PM) FrankL: Hi, all
(4:29:41 PM) liheng: Hello, everyone
(4:29:59 PM) sb: hi
(4:30:24 PM) Dieter__: Hi all :-)
(4:31:36 PM) Matthias: Hi all
(4:31:42 PM) xiuzhi: hi all
(4:31:54 PM) Matthias: xiuzhi: moin
(4:32:16 PM) Matthias: liheng: hi
(4:32:19 PM) xiuzhi: mhu:moin & goten tag
(4:32:30 PM) Matthias: :-)
(4:32:52 PM) liheng: Matthias: Hi :)
(4:33:08 PM) Dieter__: liheng + xiuzhi: hi!
(4:33:30 PM) liangjun: hello :)
(4:33:31 PM) xiuzhi: Dieter__:Hi moin
(4:33:53 PM) liheng: This is agenda
(4:33:54 PM) liheng: Topics: 1.To discuss weighting and testing-cases of User Experience Index 2.To continue discuss improving loading/saving with asynchronous processing media files
(4:34:26 PM) liheng: I had to attend a meeting so YuGuoqiang sent it to you all:)
(4:35:01 PM) Matthias: yes, we received the agenda
(4:35:56 PM) liheng: Dieter__:By the way, we can get some suggestions for Incubator Project from chinese forum :(
(4:36:31 PM) Dieter__: liheng: some negative feedback?
(4:37:20 PM) liheng: only 2 feedback, one is agree, other is from Peter
(4:37:43 PM) Matthias: liheng: can you explain in a few words, what "chinese forum" that is, please ?
(4:39:11 PM) Dieter__: liheng: the feedback on the dicsuss list at OOo is pretty good and I will ask Louis on Monday to accept and create the Performance project
(4:39:51 PM) liheng: Matthias:I choose two forum websites ,CSDN.net and BlUG(Beijing Linux User Group) to publish our proposal of Performance Project to get some suggestions:)
(4:40:08 PM) liheng: Dieter__:Thank you very much!:)
(4:40:33 PM) Dieter__: liheng: you're welcome!
(4:41:11 PM) liheng: We have published the UEI(User Experience Index) case description and weighting on wiki, http://wiki.services.openoffice.org/wiki/UEI
(4:41:40 PM) Malte: Thanks :)
(4:42:09 PM) Malte: For me, most of them look quite reasonable
(4:42:27 PM) Matthias: liheng: okay, thanks for the explanation
(4:42:43 PM) Malte: I have one suggestion to UEI:
(4:43:19 PM) liheng: Matthias:You are welcome!
(4:43:22 PM) Malte: We should completely seperate Startup Cold/warm, because it's relevant for the EI
(4:43:29 PM) Malte: UEI...
(4:43:50 PM) Malte: Slow warm start has a much higher UEI than cold start, IMHO
(4:44:05 PM) Malte: Cold start UEI should be smaller than load/save docs
(4:44:19 PM) Malte: Warm start ,ight be higher
(4:45:06 PM) liheng: Malte:Yes,so we rise proportion of warm start to 65%
(4:45:54 PM) Malte: I would suggest to leave warm start UEI on 80, but set cold start UEI to 50-60
(4:46:09 PM) Matthias: Malte: but you always start your day with a Cold Start of OOo ... and than have it open all day ... so I see it more important
(4:46:37 PM) liheng: Malte:
(4:46:52 PM) Malte: I don't think that the cold start UEI should be higher than load/save
(4:47:06 PM) Malte: load/save is done much more often
(4:47:17 PM) Malte: and also warm start is done much more often
(4:47:26 PM) Matthias: maybe not
(4:47:44 PM) FrankL: Has the index been tested with real users?
(4:48:42 PM) liheng: FrankL:We get some suggestions from end users by Product Dept CH2000
(4:49:44 PM) yugq: I think the Most Important aspect comes from the First Impression, so I think cold start is more important than warm start. From another point of view, the performance of warm start depends on cold start, so UEI of cold start should be higher :)
(4:49:47 PM) liheng: Malte:We make cold/start in a value because they do some things but system context is different
(4:51:01 PM) liheng: Malte: And startup is the highest weighting in all item
(4:51:25 PM) FrankL: But what happened more often. Cold or warm start?
(4:52:07 PM) FrankL: Also saving documents seems a major task for users and we have autosave that runs every 10 Minutes by default.
(4:52:40 PM) liheng: But we get situation from end-user maybe cold:warm is 35:65
(4:52:50 PM) Matthias: well, the distinction between "cold" and "warm" start is a complex function of the "system" and it's usage history.
(4:53:55 PM) Matthias: ...and "cold" and "warm" start situations may occur multiple times a day in succession
(4:54:23 PM) Matthias: ...in particular with portable (laptop) computers
(4:54:30 PM) liheng: FrankL:We effort to make saving to asynchronous and increasmental
(4:54:47 PM) FrankL: If quick starteris not installed.
(4:55:03 PM) yugq: FrankL: I agree save is more often happened. So UEI of it should be higher than others. But cold start and warm start have some relationship. If the cold start performance is good, then warm start also perform good.
(4:55:22 PM) FrankL: liheng:OK. That would be very good!
(4:55:39 PM) Matthias: not every operating system has a "quick starter" (or may not have the memory for it) (or may have a SSD where startup is faster) (...)
(4:56:34 PM) liheng: Matthias:I agree!
(4:56:46 PM) Matthias: liheng: :-)
(4:58:27 PM) FrankL: Bu the majority of users uses a system providing this technical helper ;-)
(4:58:37 PM) Matthias: how do you know ?
(4:59:11 PM) Matthias: maybe the majority will use Intel ClassMate PCs with Linux in the future
(4:59:18 PM) FrankL: By download numbers and hopefully by usage tracking which will start with OOo 3.1.
(4:59:21 PM) liheng: Malte:We already have risen the warm start to 65%,we think it's enough :)
(5:00:41 PM) Malte: Well, maybe I was not clear enough - I don't talk about the "proportion", but the "Weighting of Item".
(5:01:21 PM) Matthias: and the overall weighting is "start = 80", "save = 70" , "load = 60", so what would be missing here ?
(5:01:23 PM) FrankL: Each user has a different feeling of what is an acceptable performance. Furthermore it depends on the tasks the user iis doing and the situation the user is in.
(5:02:31 PM) Matthias: FrankL: sure, nobody questions that
(5:03:23 PM) Malte: mhu: I miss that I agree on start weighting > load/save for the warm start, but not for cold start.
(5:03:26 PM) Malte: My opinion.
(5:03:29 PM) liheng: FrankL+Matthias:These survey items is common, and we need only evaluating majority value
(5:03:51 PM) Matthias: Malte: but all others agree here
(5:04:06 PM) FrankL: mhu: OK. But if we agree to use an index to measure if the performance is OK, we should be sure that this index works for sure.
(5:04:15 PM) Malte: But I was asked for my opinion, so I state it...
(5:04:22 PM) Malte: I didn't say I want to discuss further
(5:04:22 PM) xiuzhi: Let's see one case. When you want to look through one webpage, if the open time is more than 3s ,Nomally one people will give up
(5:05:14 PM) Malte: Right, but the browser start-up is allowed to take 10s ;)
(5:06:02 PM) sb: I am not sure whether it is worth it to discuss the details of the index: Startup is considered slow, load is considered slow, save is considered slow. We need to work on all three. Working on them will reduce the index number. For now, that IMO is enough to guarantee that we are on track. Once things have settled, we can revisit the index calculation.
(5:06:33 PM) FrankL: I will prepare usage scenarios to get a common understanding when performance issues occur.
(5:06:33 PM) Matthias: right
(5:07:01 PM) Malte: Maybe I misinterpret the index.
(5:07:12 PM) Malte: For me the values don't change when we optimize OOo
(5:07:20 PM) Matthias: FrankL: please consider also hardware that maybe common in 1 or 2 years (nettops ...)
(5:07:40 PM) Malte: They are not "priorities" for working on items, but "state what is important for users
(5:08:09 PM) sb: Malte: I think the UEI is calculated as follows (correct me folks if I am wrong):
(5:08:13 PM) FrankL: mhu: OK
(5:08:28 PM) xiuzhi: Malte: normally it is right. so the weight between startup and load and save need to gather more end-users feeling. but now the startup is P1
(5:08:30 PM) liheng: I think we make first report with is table, and we discuss again with the result:)
(5:08:31 PM) Matthias: FrankL: thanks
(5:08:55 PM) Matthias: sb: yes?
(5:09:54 PM) sb: Take actual measurements (in seconds) of startup/cold, startup/warm, load/large, load/small, etc. Combine startup = startup/cold*.35 + startup/warm*.65, etc. Combine sum = 80*startup + 60*load + ...
(5:10:07 PM) sb: right?
(5:10:13 PM) Matthias: right
(5:10:30 PM) liheng: sb:Yes
(5:11:49 PM) Malte: Right - so the weight value means "What is important for the user", and not "what is good/bad now".
(5:12:08 PM) Matthias: right
(5:12:40 PM) Malte: So I don't understand the statement above: "Working on them will reduce the index number"
(5:12:57 PM) Malte: I will reduce the calculated value, but not the weight value
(5:13:12 PM) Matthias: yes, of course
(5:13:12 PM) Malte: And the weight number is the thing we discuss now
(5:13:32 PM) Matthias: no, all except you have agreed on the current weights
(5:14:16 PM) Malte: I "agreed but committed", as I said before
(5:14:26 PM) sb: Malte: I argue that the weight numbers are of little importance, and there probably will never be weights that satisfy all situations, anyway. Just using "random" values for now should work.
(5:14:51 PM) Matthias: thanks, Stephan
(5:15:26 PM) sb: Just one nit: you can reduce the weights by their common factor 10 ;)
(5:15:30 PM) liheng: Malte:I think we make first report with is table, and we discuss again with the result:)
(5:15:55 PM) Malte: Fine for me...
(5:16:58 PM) liheng: Ok,we have 15 minutes for 2nd topic,To continue discuss improving loading/saving with asynchronous processing media files
(5:17:46 PM) Matthias: yes, interesting results
(5:17:53 PM) xiuzhi: JackieSun: hello
(5:18:19 PM) JackieSun: xiuzhi: I am here
(5:18:33 PM) xiuzhi: JackeSun: :)
(5:18:54 PM) odf-mib: I agree. In particular for loading, I don't think that there must be a difference between the linked and the embedded case.
(5:19:20 PM) Matthias: yes, I would also not have expected that factor 2 diff
(5:19:51 PM) odf-mib: JackieSun: In the linked case, you load JPGs. Are using PNG or JPG in the embedded case?
(5:19:58 PM) Malte: factor 2 might be png/jpg issue
(5:20:26 PM) odf-mib: Malte: Yes, that was the background of my question.
(5:20:28 PM) Malte: test needs to be done with corrected documents
(5:20:53 PM) JackieSun: odf-mib: I am sorry for I am not sure
(5:21:24 PM) Malte: yugq: Would you please do the test again and post results?
(5:21:40 PM) yugq: Malte, sure.
(5:21:58 PM) Malte: Thanks :)
(5:22:17 PM) JackieSun: in the maillist, somebody think that downscaling the image is not agreeable
(5:23:11 PM) JackieSun: in some special field, like magzine, printing, they must need the high-res image
(5:23:33 PM) yugq: Malte, I think I didn't describe the problem clearly in the first mail. So I'll verify the test and report it again. But it will be next week:)
(5:23:37 PM) odf-mib: JackieSun: I think we should revisit this when we know that we are talking about the same data for linked an embedded cases
(5:24:56 PM) liheng: JackieSun:I can't agreed, the original image must pack into file, if we do downscaling, we lost data without asking user
(5:25:32 PM) lihen1: JackieSun:I can't agreed, the original image must pack into file, if we do downscaling, we lost data without asking user
(5:25:41 PM) yugq: odf-mib: It really happened not the same in the two case.
(5:26:02 PM) JackieSun: lihen: yes. I has changed my option
(5:26:11 PM) odf-mib: If we have solved that issue (or do know that we can't solve this), we should check if downscaling is an option.
(5:26:13 PM) Malte: I would add a option to OOo (Impress):" Optimize new images for screen display"
(5:26:28 PM) Malte: Then all newly inserted images can be optimized
(5:26:45 PM) Malte: Doesn't affect old documents
(5:27:08 PM) odf-mib: Malte: I'm still not convinced that we need this option.
(5:27:22 PM) Malte: UX might have an opinion.
(5:27:26 PM) JackieSun: in the maillist, the result is two ways: one is keeping the downscaled image to display in screen and ori-image to print etc.
(5:27:46 PM) Malte: IMHO people want small files, w/o using an extra step like the presentation minimizer
(5:27:54 PM) Malte: And of course w/o thinking about it ;)
(5:28:22 PM) FrankL: Malte: Then the image will be reduzed when saving. I user decides to enlarge the image again, then the data she need is gone.
(5:28:25 PM) odf-mib: I'm fine with it it turns out we need it. But first, I would like to understand why the embedded case is so much slower, and I would like to learn from UX whether the times for the linked case are acceptable.
(5:28:29 PM) Malte: Problem might be resizing the image after insertion
(5:28:35 PM) JackieSun: another is give an option to let user decide whether save the ori-image
(5:28:42 PM) xiuzhi: odf-mib: I prefer option for that,
(5:28:49 PM) Malte: Sure, this is not a workaround for performance
(5:30:03 PM) odf-mib: If we want to have this optioin for other reasons or anyway, then this is fine for me.
(5:30:22 PM) lihen1: Malte:We can create thumbnail for screen displaying
(5:30:50 PM) FrankL: and interlaced loading of images...
(5:30:54 PM) JackieSun: yes, only the downscaled image for screen displaying
(5:31:13 PM) Malte: If the original (big) image is in the file, then I would prefer loading to be fast, instead of caching reduced images :)
(5:31:32 PM) odf-mib: Before we discuss the options we have: Wouldn't it be better to get new numbers for the linked/embedded comparison first, and to understand them?
(5:31:35 PM) Malte: And I don't think that interlaced loading makes much sense in ODF
(5:31:54 PM) Matthias: the data loss argument is also relative, I think, as usually inserting an image means to insert a copy (by value) from a picture gallery (not the original file reference). So, I can reinsert it a dozen times if I so like.
(5:31:55 PM) Malte: The file is already local, interlaces loading is for slow connections
(5:32:48 PM) FrankL: Malte: I can give you a demo with a larger document in Writer. Or think about Impress.
(5:33:17 PM) Malte: The demo will show me that it's slow, but I doubt it will convince me the interlaces loading would help
(5:33:21 PM) lihen1: FrankL:Please send me a copy:)
(5:33:39 PM) lihen1: FrankL: Please send me a copy:)
(5:33:49 PM) Malte: I guess you want delay load, not interlaces load
(5:33:54 PM) FrankL: I will create a demo document that we can share.
(5:34:43 PM) lihen1: Malte:Yes, I really want to do lazy process for all media objects
(5:34:43 PM) FrankL: Malte: My intention is to be able to scroll through the document while images are loading.
(5:34:50 PM) odf-mib: yugg,JackieSun: Could you repeat your linked/embedded test with a downscaled version of the image. If we compare this with the test results for the original image, we should get some better understanding how much time we can save.
(5:35:09 PM) JackieSun: ok
(5:35:52 PM) lihen1: odf-mib:OK, we will do a group of test for this, and send the result and documents to you all
(5:36:24 PM) Malte: Thanks! :)
(5:36:27 PM) odf-mib: liheng: Thanks.
(5:37:07 PM) lihen1: It's my pleasure :)
(5:37:45 PM) JackieSun: let's go home?
(5:38:08 PM) lihen1: JackieSun:That all for me:)
(5:38:16 PM) Matthias: yes, have a nice weekend
(5:38:20 PM) JackieSun: i will late for the bus.......
(5:38:37 PM) JackieSun: ok, see you next time
(5:38:38 PM) lihen1: Matthias: Same to you
(5:38:43 PM) xiuzhi: JackieSun: see you
(5:38:48 PM) Matthias: thanks, bye all
(5:38:53 PM) odf-mib: Have a nice weekend. Bye
(5:38:58 PM) Malte: Thanks, bye :)
(5:39:03 PM) lihen1: Bye!
(5:39:14 PM) FrankL: bye!
