[Development] RFD: plugins vs QStringLiterals

Thiago Macieira thiago.macieira at intel.com
Thu Nov 5 22:03:36 CET 2015

On Thursday 05 November 2015 15:50:17 Thiago Macieira wrote:
> On Thursday 05 November 2015 18:23:37 Robin Burchell wrote:
> > On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > > Problem: performance impact, complexity of the atom/quark solution.
> > > 
> > > to lessen the performance impact, we could have a #define to control the
> > > construction behavior of QSL at compile time. i'm not quite sure whether
> > > to make that opt-in or opt-out (safety vs. performance).
> > 
> > Is the problem only apparent inside of plugins? Do we have a way to
> > detect whether someone is building plugin code at build time? (CONFIG +=
> > plugin for qmake, I guess?) If so, couldn't the behaviour of
> > QStringLiteral differ for code inside of plugins, to that outside of
> > them?
> Plugins and any library loaded by plugins that hadn't been loaded before.

Q: How often does this happen?

A: It happens for virtually EVERY GUI Qt application because QtGui loads all 
imageformat plugins, which means QtSvg gets loaded whether you wanted it or 
not. It happens again on XCB because the platform plugin links to its private 
QtXcbQpa library, which in turn links to QtDBus.

It gets worse if you have KF5-based image format plugins, since kimg_eps.so 
links to QtPrintSupport. Fortunately, none of them today link to other KF5 
libraries, but can we continue to count on that?

Note: the imageformats are loaded via QPluginLoader, so they aren't unloaded. 
The QPA platform plugin is loaded via QFactoryLoader, so it gets unloaded.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list