Lightweight API for localization of images, icons, etc.

[Chusslove Illich]

> [: Chusslove Illich :]
> I don't know if the benchmark is any good, as everything is cached by the
> OS already. [...]

Second installment. I generate 100,000 icons of same size and within one
theme, but scattered randomly across categories; 10,000 of those (one tenth)
are given localized version for sr. Then I loop KIconLoader::iconPath() on
2,000 names (not paths) of dummy icons, randomly selected. With cold start,
where I do ls -lR in my SVN tree (takes ~4 mins) and use time-based seed for
random generator, and warm start, where I rerun the loop many times in a row
with fixed seed. The timings are:

  KIconLoader::iconPath()

  without i18nFilePath:
      cold: 31 sec (sample: 31.2, 30.6, 31.1)
      warm: 5.7 sec

  with i18nFilePath, langs: fr:de:sr (i.e. when l10n present all checked):
      cold: 36 sec (sample: 35.4, 35.2, 36.7)
      warm: 5.9 sec

and if I actually load the icons, where each dummy icon is only ~200 bytes
(16x16 with few colors), and icon cache is removed before each run:

  KIconLoader::loadIcon()

  without i18nFilePath:
      cold: 53 sec (sample: 52.8, 51.2, 54.7)

  with i18nFilePath, langs: fr:de:sr (i.e. when l10n present all checked):
      cold: 58 sec (sample: 56.2, 60.1, 57.3)

(no warm starts here, as then icons are cached). Predictably, the delta is
like for the iconPath(), but that make the relative gap twice less.

This is in debugfull build. Note that the problem setup is improbably worse
case: far too great proportion of localized resources, too many languages
which fallback to the very end, tiny actually loaded resource.

To my sensibility, this test absolves the proposed l10n scheme of
performance hogging :)

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080118/906c626b/attachment.sig>