Re: refactoring OUString

On 07.06.2011 13:15, tora - Takamichi Akiyama wrote:
> As many already know, malloc() is too general and too expensive.
> Moreover, free() is much more expensive than malloc().
> e.g. a source code of malloc() in glibc:
> http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c

We use our own implementation, rtl_allocateMemory (see 
sal/rtl/source/alloc*). But of course the point remains valid: Both 
allocation and deallocation take time.

> Even though current OpenOffice.org runs as a multi-thread process,
> it runs as if it is a single thread. So, we could have several options
> to implement its underlying memory allocation mechanism for the specific
> purposes of OpenOffice.org.

If there was only a single thread, we could get rid of quite some 
locking overhead. But in fact, with clipboard, UNO acceptor thread and 
such stuff, we have just enough multithreading going on to cause the 
overhead, without the benefit of actually doing work in parallel.

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.

> 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.

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.

> I think the above are just a tip of potential, brilliant ideas.
> Let's discuss later this kind of topic once the surrounding situation is
> settled.

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

Niklas
-- 
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help