Details
-
Task
-
Resolution: Done
-
P2: Important
-
None
-
None
-
717ae864d258568e3dc94cd2d43b7b9d6375a222 a32bed7047469273cc8513cad7b2923d60f8d590 f781d97e141632c646da09888c9612931f7c928b b287ed4c4dee9d705073badc79cdb0c3e183d19b 2ce7959eb9e69cd68013fc6a0f77a9556a84365b
Description
Having the profiler itself be as optimized as possible allows it to provide a more accurate representation of the performance of a QML app. The profiler has undergone a number of revisions since it was initially introduced, and probably has additional opportunities for optimization at this point. For example:
- The profiler never sends messages directly; they are always queued.
- Can we delay more data conversions (QUrl->QString, char*->QString, etc) until sendMessages?
- Can we remove the overhead of an extra function call to processMessage (e.g. can it be made inline)?
- With many of the RAII structures it seems we are checking enabled multiple times. For example in the constructor/destructor and also in startRange/endRange. Can some checks be removed, or can we effectively use Q_LIKELY/Q_UNLIKELY here?
- Can messages be compressed? For example, can range start and location be compressed into a single event in most cases (instead of needing both startRange and rangeLocation)? Are rangeLocation and rangeData ever redundant?