Actually, yes. I'm glad to hear that we have a better implementation. If we can avoid locking as much as possible. UTF2 should help in this regard.
-- Michael Leibowitz Software Engineer, Channel Platform Solutions Group Intel Corporation michael.leibowitz at intel.com +1 503 264 7621 >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Friday, November 03, 2006 3:39 AM >To: [email protected] >Subject: Re: [dev] Bounty for performance improvements > >Hi Michael, > >slightly off topic, but speaking of performance improvements: Didn't >these numbers about the expense of the reference counters on older Intel >processors (pre Hyperthreading, say Pentium III) come initially form you? > >I changed the implementation of the reference counters in m191 so on >older processors should we see 5-6 percent improvements on the more >notorious docs while hopefully not damaging the performance for current >CPU's. > >Heiner > >Leibowitz, Michael wrote: >> 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] >> > > >-- >Jens-Heiner Rechtien >[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]
