Adding QT_NO_CAST_FROM_ASCII/ QT_NO_CAST_FROM_BYTEARRAY/QT_NO_CAST_TO_ASCII?

[Friedrich W. H. Kossebau]

Hi,

being annoyed that all marble-using apps started so slowly in valgrind, I also 
had a look at things with valgrind --tool=callgrind, and saw quite some cycles 
being spent in Marble::FileLoader due to lots of QString::operator==(const 
char*), which each bring a QString::fromUtf8 call, so quite expensive due to 
the malloc involved for the temporary QString.
I changed that yesterday with commit 8a7167afce107843e44bfa7d767e26d0241d494b 
("FileLoader: cache placemark->role() and use QLatin1String for comparing"), 
and next to improved numbers in massif-visualizer I could also feel how e.g. 
marble & marble-qt start much quicker now.

While in the other callgrind measurements done there were no similar high-
ranked issues with QString::operator==(const char*), there are still some of 
those calls in hot-paths both in rendering and loading.

So I wonder what you think of enforcing things with the definitions 
QT_NO_CAST_FROM_ASCII & friends, to avoid those sand grains in the Marble 
engine and not adding up and also to prevent future bigger glitches again?

Con:
* plain "foo" is simpler to write and read
Pro:
* lots of places already use QLatin1String/QStringLiteral, so more consistent
* quicker at runtime & less memory pollution from temp allocs

I would volunteer to do (most of) the needed changes by the time :) At least 
start with src/lib, and then slowly extend to the plugins until this can be a 
project wide setting.

Cheers
Friedrich