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 dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
