It's very easy to measure how long it takes to open a file. You can use the UNO API and gettimeofday. If just want something quick and dirty, you can just use RTL_LOGFILE.
However, figuring out what is a typical document is not. For our performance profiling, we have a collection of about 100 documents culled from inside of Intel. This is an imperfect sample, and we've never felt comfortable with a particular set of documents as being representative. BTW, I'd also like to plug i#53055 at this time for speeding .doc imports (it even saves memory) -- Michael Leibowitz Software Engineer, Channel Platform Solutions Group Intel Corporation michael.leibowitz at intel.com +1 503 264 7621 >-----Original Message----- >From: Utomo [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 01, 2006 8:07 PM >To: [email protected] >Subject: RE: [dev] Bounty for performance improvements > >Thanks for the suggestions. > >My original idea was. >To make Ooo faster opening the Microsoft Office files. (but without adding >memory usage by OOo) >Especially for user with old computer, such as PIII with around 128 memory >(which now mostly suffer from the huge memory usage by Ooo, and they feel >very long time opening the Microsoft office files). I hear many PIII user >complain about this, and this make them stop using Ooo. And I think it need >to be improved, so it can make them happy and use Ooo. > >(I will provide some test file when the bounty start.) > >Example: >Original Ooo without patch open the file in 60 second >Ooo with patch open the file in 30 second >In My opinion this is a 50% Improvements. > >But sometimes it is not easy to measure how long opening a files is. >( I think judges will help decide it) > >What do you think ? > >Best Regards, > > >Utomo > > > >-----Original Message----- >From: Andrew Douglas Pitonyak [mailto:[EMAIL PROTECTED] >Sent: Thursday, November 02, 2006 10:35 AM >To: [email protected] >Subject: Re: [dev] Bounty for performance improvements > >Utomo wrote: >> I am waiting and open for suggestions. >> Is there somebody can help me to determine how is the performance >> improvements measured ? >> >> Utomo >I have a few comments: > >Performance should be quantified and explained by the submitter. In >other words, the submitter should indicate how to test and demonstrate a >speed improvement. > >Memory and runtime both sounds like improvements to me. > >Broader impact should carry more weight. For example, a 100% improvement >in sort speed is probably not as important as a 10% improvement in >screen redraw time because the screen is almost always updated. By the >same token, a 10% improvement in screen redraw may also beat a 20% >improvement in macro run-time. > >I would probably use imprecise statements as those, and then after some >prioritizing, leave the final decision to public voting if it is not >obvious as to the final winner, or simply decide up front, that public >voting will be done. > >-- >Andrew Pitonyak >My Macro Document: http://www.pitonyak.org/AndrewMacro.odt >My Book: http://www.hentzenwerke.com/catalog/oome.htm >Info: http://www.pitonyak.org/oo.php >See Also: http://documentation.openoffice.org/HOW_TO/index.html > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
