On Fri, Jun 10, 2011 at 6:51 AM, tora - Takamichi Akiyama
t...@openoffice.org wrote:
Sorry, this mail is too long...
No problem, I'll briefly go through your five items one by one:
1. Delegation of the responsibility to choose a type of memory allocator
To achieve both stability and
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
On Thu, Jun 9, 2011 at 9:20 AM, tora - Takamichi Akiyama
t...@openoffice.org wrote:
That is why I would like to encourage programmers to take care of the life
time of data.
First of, I am doubtful that encouraging manual memory management is a good
idea. Errors in manual memory management
Sorry, this mail is too long...
On Thu, Jun 9, 2011 at 9:20 AM, tora - Takamichi Akiyama t...@openoffice.org
mailto:t...@openoffice.org wrote:
That is why I would like to encourage programmers to take care of the life
time of data.
I know that that statement is controversial.
On
Am 06.06.2011 17:27, schrieb Michael Stahl:
On 06.06.11 16:35, tora - Takamichi Akiyama wrote:
Has anyone tried refactoring OUString?
- It converts iso-8859-1 letters ranging 0x00-0x7f into UCS2 even it is not
necessary.
- It requires malloc(), realloc(), and free() or their
On 06.06.2011 19:43, tora - Takamichi Akiyama wrote:
And also, please cover the underlying memory allocation mechanism which
would be another key factor for the performance improvement.
On 2011/06/07 3:04, Niklas Nebel wrote:
There's an old suggestion to treat small strings differently, see
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
On 07.06.2011 17:22, Niklas Nebel wrote:
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:
On 06.06.11 16:35, tora - Takamichi Akiyama wrote:
Has anyone tried refactoring OUString?
- It converts iso-8859-1 letters ranging 0x00-0x7f into UCS2 even it is not
necessary.
- It requires malloc(), realloc(), and free() or their equivalents.
- It prevents debugging efforts because
On 2011/06/07 0:27, Michael Stahl wrote:
refactoring OUString has to be done carefully because it is a central part
of the URE API/ABI and those must be compatible.
a number of people here have come to the conclusion that it would be an
improvement to use ::rtl::OString with UTF8 encoding as
On 06.06.2011 18:57, tora - Takamichi Akiyama wrote:
On 2011/06/07 0:27, Michael Stahl wrote:
refactoring OUString has to be done carefully because it is a central
part
of the URE API/ABI and those must be compatible.
a number of people here have come to the conclusion that it would be
On 06.06.2011 18:57, tora - Takamichi Akiyama wrote:
This is just an idea. How about adding a new class besides OUString?
On 2011/06/07 2:16, Mathias Bauer wrote:
We already have enough string classes. :-)
Yes, we have! :-)
Besides that, you are right, rtl::OUString is stupid. We planned
On 06.06.2011 19:43, tora - Takamichi Akiyama wrote:
And also, please cover the underlying memory allocation mechanism which
would be another key factor for the performance improvement.
There's an old suggestion to treat small strings differently, see
13 matches
Mail list logo
