Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Optimal replacing windowTitle with new QString
Forum Updated to NodeBB v4.3 + New Features

Optimal replacing windowTitle with new QString

Scheduled Pinned Locked Moved Unsolved General and Desktop
9 Posts 5 Posters 845 Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    RedSoft
    wrote on 14 Feb 2019, 12:25 last edited by RedSoft
    #1

    I am writing Qt-based application and need to update MainWindow Title each time a user changes an active document. The title is build as follows: "AppName - <DocumentName>". If I understand correctly, when I set new title via QWidget::setWindowTitle method, the old QString title is deallocated and new one is set. But it can result a lot of malloc/free calls during my application executing. Is it possible to preallocate QString for title with some spare for long DocumentName string, and after 1st setWindowTitle to get a reference (not a copy) to this new title string in order then only to replace the needed part in existent title, and then somehow force this updated title to be refreshed?

    1 Reply Last reply
    0
    • M Offline
      M Offline
      mrjj
      Lifetime Qt Champion
      wrote on 14 Feb 2019, 12:30 last edited by mrjj
      #2

      Hi
      QString is implicitly shared - so i would not worry about memory fragmentation
      setting the Windows title.
      https://doc.qt.io/qt-5/implicit-sharing.html

      However, the final setting of the title via the OS, will copy/allocate so
      I think there is no way to make this very effective.
      However, unless its an extremely small board you run app on,
      the title setting should not be an issue.

      R 1 Reply Last reply 14 Feb 2019, 15:44
      5
      • M mrjj
        14 Feb 2019, 12:30

        Hi
        QString is implicitly shared - so i would not worry about memory fragmentation
        setting the Windows title.
        https://doc.qt.io/qt-5/implicit-sharing.html

        However, the final setting of the title via the OS, will copy/allocate so
        I think there is no way to make this very effective.
        However, unless its an extremely small board you run app on,
        the title setting should not be an issue.

        R Offline
        R Offline
        RedSoft
        wrote on 14 Feb 2019, 15:44 last edited by RedSoft
        #3

        @mrjj Implicit sharing works when several clients own one shared QString data for reading purpose, writing should also update all. But in the described by me case, setWindowTitle caller allocates new string in his own memory (e.g. stack) and then passes it to the Qt engine. I do not mean the possible resulted overhead in the OS underlying mechanism, cannot eliminate it. But if Qt keeps some QString copy for each windowTitle, I would like reuse its buffer each time I update the title.

        M 1 Reply Last reply 14 Feb 2019, 15:52
        0
        • R RedSoft
          14 Feb 2019, 15:44

          @mrjj Implicit sharing works when several clients own one shared QString data for reading purpose, writing should also update all. But in the described by me case, setWindowTitle caller allocates new string in his own memory (e.g. stack) and then passes it to the Qt engine. I do not mean the possible resulted overhead in the OS underlying mechanism, cannot eliminate it. But if Qt keeps some QString copy for each windowTitle, I would like reuse its buffer each time I update the title.

          M Offline
          M Offline
          mrjj
          Lifetime Qt Champion
          wrote on 14 Feb 2019, 15:52 last edited by
          #4

          Hi
          It seems not possible to have access to that buffer as its part of private d class.
          https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html

          QString QWidget::windowTitle() const
          {
              Q_D(const QWidget);
              if (d->extra && d->extra->topextra) {
                  if (!d->extra->topextra->caption.isEmpty())
                      return d->extra->topextra->caption;
                  if (!d->extra->topextra->filePath.isEmpty())
                      return QFileInfo(d->extra->topextra->filePath).fileName() + QLatin1String("[*]");
              }
              return QString();
          }
          
          1 Reply Last reply
          0
          • V Offline
            V Offline
            VRonin
            wrote on 14 Feb 2019, 16:20 last edited by VRonin
            #5

            Donald Knuth said

            Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

            "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
            ~Napoleon Bonaparte

            On a crusade to banish setIndexWidget() from the holy land of Qt

            1 Reply Last reply
            8
            • A Offline
              A Offline
              aha_1980
              Lifetime Qt Champion
              wrote on 14 Feb 2019, 16:57 last edited by
              #6

              Full ack to @VRonin.

              @redsoft: if you set the window title 1000 times per second(*), it may be a problem. But if you do, you already have a bigger one.

              If you set the title, let's say every 2 seconds, there are much more other memory allocations/deallocations already done in background, so your's really don't matter.

              (*) And even if you do, it has to be proven, that malloc is really the limiting factor in that case.

              Qt has to stay free or it will die.

              R 1 Reply Last reply 15 Feb 2019, 00:37
              2
              • A aha_1980
                14 Feb 2019, 16:57

                Full ack to @VRonin.

                @redsoft: if you set the window title 1000 times per second(*), it may be a problem. But if you do, you already have a bigger one.

                If you set the title, let's say every 2 seconds, there are much more other memory allocations/deallocations already done in background, so your's really don't matter.

                (*) And even if you do, it has to be proven, that malloc is really the limiting factor in that case.

                R Offline
                R Offline
                RedSoft
                wrote on 15 Feb 2019, 00:37 last edited by RedSoft
                #7

                @aha_1980 In general I can agree with you and @VRonin. But you should understand, that if any new student starts his practice with such "allowance", we can expect from such new programmer in the future many "surprises" :) . And we are responsible for them :)
                Especially, concerning my situation, it is interesting to me because of in the nearest future I want to port my app to some resource restricted platform.

                A K 2 Replies Last reply 15 Feb 2019, 04:34
                0
                • R RedSoft
                  15 Feb 2019, 00:37

                  @aha_1980 In general I can agree with you and @VRonin. But you should understand, that if any new student starts his practice with such "allowance", we can expect from such new programmer in the future many "surprises" :) . And we are responsible for them :)
                  Especially, concerning my situation, it is interesting to me because of in the nearest future I want to port my app to some resource restricted platform.

                  A Offline
                  A Offline
                  aha_1980
                  Lifetime Qt Champion
                  wrote on 15 Feb 2019, 04:34 last edited by
                  #8

                  @RedSoft again, you are speculating. Have you proved that this task is a problem? If not, why do you worry?

                  Qt has to stay free or it will die.

                  1 Reply Last reply
                  2
                  • R RedSoft
                    15 Feb 2019, 00:37

                    @aha_1980 In general I can agree with you and @VRonin. But you should understand, that if any new student starts his practice with such "allowance", we can expect from such new programmer in the future many "surprises" :) . And we are responsible for them :)
                    Especially, concerning my situation, it is interesting to me because of in the nearest future I want to port my app to some resource restricted platform.

                    K Offline
                    K Offline
                    kshegunov
                    Moderators
                    wrote on 15 Feb 2019, 19:08 last edited by kshegunov
                    #9

                    @RedSoft said in Optimal replacing windowTitle with new QString:

                    But you should understand, that if any new student starts his practice with such "allowance", we can expect from such new programmer in the future many "surprises"

                    If you start building a house, is your first concern whether the concrete, you haven't yet poured and you're not going to for a long time, has the right consistency? I find that hard to believe. You don't start designing the window before you have a wall to put it in, you don't have a wall before you have a foundation to place it on.

                    The same principle applies. When you start considering a program you should first consider the big-picture, the major components - the data structures, the algorithms, the way it's going to be used and you design based on that. After you are satisfied with all this then you may start worrying about the minor details. The point of @VRonin's quote is not to forgo optimization, but to choose your battles. If I have a codepath that's executed once and it consists of 1% of the CPU time spend in the program if I speed it up 10 times I shed 0.9% of the CPU time. If I have a codepath executed multiple times which eats up 10% of the CPU time, if I can speed that up only twice I have accomplished 5% faster total execution.
                    So is it worth to invest time in the first case before solving the second one (and that is all assuming it's at all necessary)?

                    Read and abide by the Qt Code of Conduct

                    1 Reply Last reply
                    4

                    8/9

                    15 Feb 2019, 04:34

                    • Login

                    • Login or register to search.
                    8 out of 9
                    • First post
                      8/9
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Search
                    • Get Qt Extensions
                    • Unsolved