Remove use of QByteDataBuffer in QNetworkReplyHttpImpl

It's temporarily storing QByteArrays before we copy them directly to
QIODevice's internal buffer. We can save the extra work by just push
them directly into the buffer.

The signal compression is no longer useful performance-wise, but is
kept as it will throttle the amount of readyRead emissions the users has
to handle.

Reorder some of the operations as a result to make it more natural.

Change-Id: Ifc0481d56fec42545e95970125d883a5c68d647a
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>

1 files changed, 19 insertions, 39 deletions

diff --git a/src/network/access/qnetworkreplyhttpimpl.cpp b/src/network/access/qnetworkreplyhttpimpl.cpp
index 12dfb1c269..b3dec282b0 100644
--- a/src/network/access/qnetworkreplyhttpimpl.cpp
+++ b/src/network/access/qnetworkreplyhttpimpl.cpp
@@ -1052,59 +1052,39 @@ void QNetworkReplyHttpImplPrivate::replyDownloadData(QByteArray d)
     if (!q->isOpen())
         return;
 
-    int pendingSignals = (int)pendingDownloadDataEmissions->fetchAndAddAcquire(-1) - 1;
+    if (cacheEnabled && isCachingAllowed() && !cacheSaveDevice)
+        initCacheSaveDevice();
+
+    // This is going to look a little strange. When downloading data while a
+    // HTTP redirect is happening (and enabled), we write the redirect
+    // response to the cache. However, we do not append it to our internal
+    // buffer as that will contain the response data only for the final
+    // response
+    if (cacheSaveDevice)
+        cacheSaveDevice->write(d);
+
+    if (!isHttpRedirectResponse()) {
+        buffer.append(d);
+        bytesDownloaded += d.size();
+    }
+    bytesBuffered += d.size();
 
+    int pendingSignals = pendingDownloadDataEmissions->fetchAndSubAcquire(1) - 1;
     if (pendingSignals > 0) {
         // Some more signal emissions to this slot are pending.
         // Instead of writing the downstream data, we wait
         // and do it in the next call we get
         // (signal comppression)
-        pendingDownloadData.append(d);
         return;
     }
 
-    pendingDownloadData.append(d);
-    d.clear();
-    // We need to usa a copy for calling writeDownstreamData as we could
-    // possibly recurse into this this function when we call
-    // appendDownstreamDataSignalEmissions because the user might call
-    // processEvents() or spin an event loop when this occur.
-    QByteDataBuffer pendingDownloadDataCopy = pendingDownloadData;
-    pendingDownloadData.clear();
-
-    if (cacheEnabled && isCachingAllowed() && !cacheSaveDevice) {
-        initCacheSaveDevice();
-    }
-
-    qint64 bytesWritten = 0;
-    for (int i = 0; i < pendingDownloadDataCopy.bufferCount(); i++) {
-        QByteArray const &item = pendingDownloadDataCopy[i];
-
-        // This is going to look a little strange. When downloading data while a
-        // HTTP redirect is happening (and enabled), we write the redirect
-        // response to the cache. However, we do not append it to our internal
-        // buffer as that will contain the response data only for the final
-        // response
-        if (cacheSaveDevice)
-            cacheSaveDevice->write(item.constData(), item.size());
-
-        if (!isHttpRedirectResponse())
-            buffer.append(item);
-
-        bytesWritten += item.size();
-    }
-    bytesBuffered += bytesWritten;
-    pendingDownloadDataCopy.clear();
+    if (isHttpRedirectResponse())
+        return;
 
     QVariant totalSize = cookedHeaders.value(QNetworkRequest::ContentLengthHeader);
     if (preMigrationDownloaded != Q_INT64_C(-1))
         totalSize = totalSize.toLongLong() + preMigrationDownloaded;
 
-    if (isHttpRedirectResponse())
-        return;
-
-    bytesDownloaded += bytesWritten;
-
     emit q->readyRead();
     // emit readyRead before downloadProgress incase this will cause events to be
     // processed and we get into a recursive call (as in QProgressDialog).