Re: refactoring OUString

On 2011/06/08 0:22, Niklas Nebel wrote:
> Of course we should try to make more use of multiple threads. This isn't a new idea either, see http://wiki.services.openoffice.org/wiki/Calc/Performance/misc. Christian did some experiments with parallel loading a while ago (http://blogs.oracle.com/GullFOSS/entry/xml_performance_and_now_for). The results for Impress weren't spectacular, but Calc or Writer may be different.

Yep! I am a multithread, data-driven programming lover, too. :-)

> On 07.06.2011 13:15, tora - Takamichi Akiyama wrote:
>> 2) Slicing cheese and throwing them out at once
>> For the internal tasks such as "Save as" and "Export to" we might get
>> a big advantage. Such a task starts from the framework, calls thousands
>> of methods, and finally leaves the only single value meaning a SUCCESS
>> or FAILURE. No String instance involved during the task is needed to be
>> persistent.

On 2011/06/08 0:22, Niklas Nebel wrote:
> Right now, that isn't entirely true. For example, saving might need to calculate a formula, and the calculated result is then kept in the cell, in a string that continues to be referenced after saving. There might be similar cases elsewhere. These would probably have to be moved into a separate step before saving. Sounds a bit fragile, but then it could actually save a significant amount of time.

That is why I would like to encourage programmers to take care of the life time of data.

For instance, in the user scenario below, there might be
  (1) data lasting until the soffice.bin quits.
  (2) data lasting until a document is closed.
  (3) data lasting until a current thread ends.
  (4) data lasting until a certain task finishes.
  (5) data lasting until a current function call returns.

  1. File - New - Spreadsheet
  2. work on it and save it.
  3. File - Close.

In the step 1, construct an instance of memory allocator for (2).
In the step 2, use it to allocate memory chunks lasting as long as the document is open.
In the step 3, destroy the allocator to completely free the allocated memory.

Lessons we might have learned:
  We can implement and utilize some purpose oriented memory allocators as well as the general, expensive one: malloc() and free().

  Programmers may wisely choose what memory allocator is appropriate for questioned data.


> On the other hand, now might be a perfect time to discuss "crazy ideas", without mundane details getting in the way.

Aha! here is another "crazy ideas" :-)

  https://bitbucket.org/tora/ooo-idea-zstring/src

   memory_allocator_for_zstring.cxx
     shows an idea of reusable, cache, memory allocation mechanism for new String class. The key concept here is not to actually "free" the memory being freed, but to cache it for a later use.

   Reuse the most recently freed memory first so that the Translation Lookaside Buffer (TLB) achieves higher hit ratio.

   In contrast, if the oldest freed memory is used first, the entire system performance might suffer because the relevant entry is surely absent from the TLB and, moreover, the relevant memory page might have been swapped out to a disk device.

   vec.hxx
     implements a c++ template for cheaply expandable vector.

   test_vec.cxx
     demonstrates usage of vec.hxx

Best regards,
Tora
-- 
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help