I am currently facing a performance issue in the rest API ...

through profiling i found out that most time gets consumed by calls to gettext and struct.unpack ...

digging deeper into the code and discussing with ralf we found out that the time gets consumed by calling roundup.cgi.TranslationService.get_translation (takes about 2ms).

which is not much, but ralf calls it in every detector as he wants to have i18n in the detector and there is no way to get it otherwise ... for 25 detectors, this adds a total of 60ms.

digging further into the logic of where get_translation gets called we found out that it's also not working as expected:

mail_gw: the setting in config.ini (mailgw.language) is ignored, uses ENV setting if found, default "en"

client.py: uses setting tracker.language (which, to me, is not obvious - web.language would be wore intuitive, but it's ok for me), browsers language (if enabled in settings), some "@language=code" form field (why?), ENV or "en"

for the rest api it could be optional if one wants translated error messages or speed - using the NullTranslatior i gain another 2ms in speed per request

to sum up what we (ralf and me) suggest as an enhancement:

  put the "get_translation" functionality somewhere in the hyperdb, to have a i18n object there
  initialise it with the NullTranslator (as this merely costs nothing) and 
  change this if needed down the way (be it in the mail_gw, cli or cgi handler)
  add config item rest_no_translation and xmlrpc_no_translation (or maybe own sections for rest and xmlrpc)

this way:

  detectors can access gettext (through db.i18n) and provide localized error messages, 
  web_interface, cli and mail_gw can change the language if needed
  if nothing gets set by the user, we have maximum speed :)

free for discussion .. ;)

regards,
marcus.