Hi,

I have some performance problems with qTranslate and Atahualpa. I read one post (of which I can not find the link) that suggested the incompatibility between the two.

I also did some performance testing. I came to the same conclusion that qTranslate or Atahualpa by itself work OK but together it's a performance hog.
Here are the conclusions of the testing I did if it will be of any help.

On my girl's blog I found out that there are two weak points:
- loading posts (i didn't look further into this),
- loading category menus on the top of the page.

Some statistics:

Pageload for Atahualpa + qTranslate = 2s
- of this categories = 0,5s
- posts (6 excerpts) = 0,5s
- qTranslate = 1,2s ; 9300 queries

Pageload for Atahualpa = 1s
- categories = 0,16s
- posts = 0,4s

Pageload for qTranslate = 1s;
- of this for qTranslate = 0,3s ; 3400 queries

To where I digged:
- atahualpa/index.html (post are in while loop, categories in "get_header" function);
- get_header opens atahualpa/header.php, in which the "bfa_header_config" causes most delays;
- bfa_header_config opens atahualpa/functions/bfa_header_config.php and calls "bfa_hor_cats";
- atahualpa/functions/bfa_hor_cats.php calls wp_list_categories.
If I comment this line, page loads significally faster.
I experimented in qtranslate_hooks.php with some success, but in the process the URLs in the categories got corrupted.

Best regards,
Dominik

If anyone is interested in a partial solution - in qtranslate_core.php disable this line:
#add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',0);

Options shouldn't need to be translated anyways.

Wow, this really shaves of some time (about 33% faster).
However if I use it, then the widget titles of "Buy me a Beer" plugin is shown in both languages prefaced by the quicktags.

Any idea why this happens? All my other widge titles translate fine.
Using normal language tags it is no better (still both languages shown - only difference is that the tags themselves in this case do not show up).

Edit:
Actually I found out, that also the inserts at the end of a post by the "Buy me a Beer" plugin, are not translated anymore....

Edit: Widgets are not translated at all anymore using this hack, I had forgotten that I'm using a widget cache plugin for most widgets, hence I did not directly see the effect of them not being translated anymore.

As I'm not having any widgets which need to be translated, you can try to change the hook priority (if I correctly remember the function of that integer).

Original:
add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',0);
Suggested corrections:
add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',19);
add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',20);
add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',21);
The default priority is 20.

A little update on speeding up qTranslate.

I installed Xdebug (http://xdebug.org/) and WebGrind (http://code.google.com/p/webgrind/) for debugging Atahualpa and qTranslate. Xdebug is probably a package in your Linux distribution (at least it comes with Ubuntu Server as php5-xdebug). Instructions can be found here: http://giorgiosironi.blogspot.com/20...5-minutes.html.

This way it can be seen that some functions are called more then 10.000 times - on a blog with 500 posts and few thousand comments.
I did a little fix:
- in qtranslate_hooks.php, line 233, add "$GLOBALS['qtHOME'] = rtrim(get_option('home'),"/");"
- in qtranslate_core.php, line 532, change "$home = $GLOBALS['qtHOME'];".
It reduced the calls of apply_filters by 10% and sped up the blog by a few percent.

I thing lots of performance improvements could be made by interpreting the debug logs.

Another optimization (in bfa_get_options.php):
foreach ($options as $value) {

$option_value = get_option( $value['id'] );
if ($option_value === FALSE) {
$$value['id'] = $value['std'];
update_option($value['id'], $value['std']);
}
else
$$value['id'] = $option_value;

$short_func_name = str_replace("bfa_ata_", "", $value['id']);
$bfa_ata[$short_func_name] = $$value['id'];

}

And "include (TEMPLATEPATH . '/functions/bfa_get_options.php'); " is called twice:
- in atahualpa/index.php;
- in atahualpa/functions.php.

Originally Posted by DSmidgy

As I'm not having any widgets which need to be translated, you can try to change the hook priority (if I correctly remember the function of that integer).

Original:
add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',0);
Suggested corrections:
add_filter('option_'.$option, 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLang uage',21);
The default priority is 20.

Setting it to 21 works great!

19 and 20 were as slow as usual. 21 Seems to run as quick as if I were disabling it by "#". It's now down to around 0.3-0.4 seconds on 404 error page, max around 1.5 seconds on normal pages with content.

Well, I did not notice everything. Above works well, if it weren't for page navigation being english only now. So currently on http://openmtbmap.org I only have German page navigation menu, it is not translated to english.

I still wonder why this happens. I'll try out tomorrow some comparisons apache vs nginx on my linux machine. I quickly tried a WEMP on Windows, but nginx does not run smooth at all for me here, and my server is currently down so I had to move my website temporarily and can't try to optimise.

edit - German titles do work. However the translations were lost during a database update. So the only problem are that widgets are not translated using the above hack.