KDE malloc speed

[Lubos Lunak]

On Saturday 19 of April 2003 11:56, Stefan Rompf wrote:
> Hi,
>
> > nowadays on a linux glibc-2.3.2 system? I've tried benchmarking the
> > loading of a big (350kb) html file by konqueror. Did it with a wristwatch
> > admittedly (what's the right way?) but could detect no gross difference.
> > Should there be
>
> on my system, KDE malloc is considerably slower for operations involving
> large data chunks, f.e. opening a huge mail with kmail over imap. I've
> tracked back the reason to a bad interaction between kde-malloc, QGArray
> and QBuffer:
>
> When adding data to a QGArray with QBuffer in QT's default
> configuration, QT optimizes for memory by realloc()ing the destination
> array on every writeBlock() call.
>
> Both on Suse 8.2 and good old Redhat 6.1, KDE malloc compiles with
> HAVE_MREMAP defined to 0. So when reallocating data chunks that are over
> the mmap limit in size, KDE malloc always copies the data, different to
> libc that just changes some memory mapping via mremap().
>
> In the result, the workload of appending n bytes in small chunks via
> QBuffer to QByteArray is an O(n^2) operation with KDE malloc, and O(n)
> with libc malloc.
>
> Now it is not clear to me whom to blame - the naive default
> implementation of QBuffer/QGArray or KDE malloc, but for my workload, I
> prefer the libc allocator.

 Does the attached patch make it better?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc.c.patch
Type: text/x-diff
Size: 261 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030422/3e214efb/attachment.patch>