On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen <oswald.buddenha...@theqtcompany.com> wrote: >> The argument is that it implies runtime overhead. See Robin's email for >> numbers. This is asking for making the code slower on the very devices where >> it needs to run faster. >> > i don't trust this number. i don't know how qMalloc was implemented, but > there is no way a simple forwarding wrapper would add 10% overhead to > malloc (esp. in an optimized build). > modern processors even have a specific optimization for call forwarding > (or whatever it's called properly).
I went and dug out the test I had. I remembered the results correctly (for OS X, for Linux the situation is somehow worse overall?). The measurement is actually qMalloc + qFree vs malloc + free, so the overhead is shared across two calls. See the attachments. Here's the results for OS X 10.10 and Linux (Ubuntu 12.04). Hopefully they don't get screwed in mail formatting :) OS X 10.10 Size ms Total Iterations qtMalloc 1 0,000055 58 1048576 qtMalloc 10 0,000056 60 1048576 qtMalloc 100 0,000059 69 1048576 qtMalloc 10000 0,00018 90 524288 qtMalloc 1000000 0,029 59 2048 qtMalloc 10000000 0,34 86 256 regularMalloc 1 0,000051 55 1048576 regularMalloc 10 0,000051 58 1048576 regularMalloc 100 0,000052 55 1048576 regularMalloc 10000 0,00013 73 524288 regularMalloc 1000000 0,029 59 2048 regularMalloc 10000000 0,4 97 256 Percentage change -0,999949 -0,999949 -0,999948 -0,99987 -0,971 -0,6 Linux Size ms Total Iterations qtMalloc 1 0,000032 68 2097152 qtMalloc 10 0,000032 68 2097152 qtMalloc 100 0,000036 76 2097152 qtMalloc 10000 0,00021 57 262144 qtMalloc 1000000 0,037 76 2048 qtMalloc 10000000 0,47 61 128 regularMalloc 1 0,00001 92 8388608 regularMalloc 10 0,000011 95 8388608 regularMalloc 100 0,000011 99 8388608 regularMalloc 10000 0,000011 97 8388608 regularMalloc 1000000 0,000011 93 8388608 regularMalloc 10000000 0,000011 96 8388608 Percentage change -0,99999 -0,999989 -0,999989 -0,999989 -0,999989 -0,999989 Looking at the instruction counts (Linux only, via callgrind) is interesting, though, and I don't know how to explain this: Linux Size Instruction reads qtMalloc 1 376 qtMalloc 10 376 qtMalloc 100 405 qtMalloc 10000 2,320 qtMalloc 1000000 95,208 qtMalloc 10000000 938,880 regularMalloc 1 179 regularMalloc 10 179 regularMalloc 100 179 regularMalloc 10000 179 regularMalloc 1000000 179 regularMalloc 10000000 179
#include <QtCore>
#include <qtest.h>
#include <qcoreapplication.h>
#include <qdatetime.h>
class MallocBenchmark : public QObject
{
Q_OBJECT
private slots:
void qtMalloc();
void qtMalloc_data();
void regularMalloc();
void regularMalloc_data();
};
void MallocBenchmark::qtMalloc_data()
{
QTest::addColumn<int>("size");
QTest::newRow("1") << 1;
QTest::newRow("10") << 1;
QTest::newRow("100") << 100;
QTest::newRow("10000") << 10000;
QTest::newRow("1000000") << 1000000;
QTest::newRow("10000000") << 10000000;
}
void MallocBenchmark::qtMalloc()
{
QFETCH(int, size);
QBENCHMARK {
void *p = ::qMalloc(size);
memset(p, rand(), size);
::qFree(p);
}
}
void MallocBenchmark::regularMalloc_data()
{
qtMalloc_data();
}
void MallocBenchmark::regularMalloc()
{
QFETCH(int, size);
QBENCHMARK {
void *p = malloc(size);
memset(p, rand(), size);
free(p);
}
}
QTEST_MAIN(MallocBenchmark)
#include "main.moc"
malloccheck.pro
Description: Binary data
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
