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