D26868: Move newItem to private method in KConfigSourceGenerator

[Tomaz Canabrava]

tcanabrava added a comment.


  In D26868#602162 <https://phabricator.kde.org/D26868#602162>, @kossebau wrote:
  
  > In D26868#602150 <https://phabricator.kde.org/D26868#602150>, @dfaure wrote:
  >
  > > There is indeed a QString overload for concatenating QLatin1String, but it will have to be converted char-by-char (from 8 bits to 16 bits), so isn't it faster to concatenate QStringLiterals?
  >
  >
  > I have never seen numbers, but any time I asked someone who might have seen numbers, they told me: QStringLiteral only for final strings not further modified or given to operations. Sadly cannot find references now, but I asked often the recent years.
  >  Looking at the code, the `qt_from_latin1` helper method might be as efficient on most processors as the `memcpy` is perhaps, and making up for any other overhead the QStringLiteral-generated code has, perhaps atomic stuff around the generated QString instance is expensive compared to the copy logic?
  >
  > But ready to hear from real Qt experts once more, perhaps with numbers this time :)
  
  
  I checked here with a really big xml file and the difference seems negligible. ( QStringLiteral 0.0s and QLatin1String 0.0s ) - I'd use QStringLiteral just for the sake of consistency across the codebase, tough

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D26868

To: tcanabrava, ervin, dfaure
Cc: kossebau, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200129/1b2ee9cf/attachment.html>