KDE malloc speed

[Stefan Rompf]

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.

Stefan
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<