Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-35315

Optimize QQmlProfilerService

    XMLWordPrintable

    Details

    • Technical Risk:
      Normal
    • Commits:
      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?

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            ulherman Ulf Hermann
            Reporter:
            mbrasser Michael Brasser
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: