Speed up string handling from QML cache files

Currently when extracting a string from a compilation unit, we copy the
data. This happens for example when instantiating objects and setting
string properties and it also happens when creating the JS runtime
strings from the compilation unit.

Since QML cache files that are mapped into memory from disk, we can
avoid the copy by keeping the files mapped and making sure that the
in-memory representation is compatible with QStringData.

This optimization is limited to little-endian architectures.

Task-number: QTBUG-63068
Change-Id: I2450aacd3bf1eda3e5be4264149b23f0281d8b4e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>

1 files changed, 10 insertions, 2 deletions

diff --git a/src/qml/compiler/qv4compilationunitmapper_unix.cpp b/src/qml/compiler/qv4compilationunitmapper_unix.cpp
index 8348613888..1fef4d38f4 100644
--- a/src/qml/compiler/qv4compilationunitmapper_unix.cpp
+++ b/src/qml/compiler/qv4compilationunitmapper_unix.cpp
@@ -92,8 +92,16 @@ CompiledData::Unit *CompilationUnitMapper::open(const QString &cacheFileName, co
 
 void CompilationUnitMapper::close()
 {
-    if (dataPtr != nullptr)
-        munmap(dataPtr, length);
+    // Do not unmap the data here.
+    if (dataPtr != nullptr) {
+        // Do not unmap cache files that are built with the StaticData flag. That's the majority of
+        // them and it's necessary to benefit from the QString literal optimization. There might
+        // still be QString instances around that point into that memory area. The memory is backed
+        // on the disk, so the kernel is free to release the pages and all that remains is the
+        // address space allocation.
+        if (!(reinterpret_cast<CompiledData::Unit*>(dataPtr)->flags & CompiledData::Unit::StaticData))
+            munmap(dataPtr, length);
+    }
     dataPtr = nullptr;
 }