gajim-remote is slow

[dottedmag@…]

[mag@vertex:~]% time gajim-remote get_status online gajim-remote get_status 0.57s user 0.03s system 97% cpu 0.613 total [mag@vertex:~]%

It's pretty annoying to see such delay. Usability engineers say 0.1-0.15 seconds is the maximum execution time of single command to do not create feeling of 'crawling'.

Probably this is related to the Python startup time, but

[mag@vertex:~]% time python /dev/null python /dev/null 0.04s user 0.00s system 95% cpu 0.045 total [mag@vertex:~]%

[dkirov]

You are right, it is slow, although on my comp (CPU ~1527Mhz) results are

3 times better.

The slowest part is importing and connecting to dbus session and binding gettext domain. I cannot see how this part can be enhanced. Removing gettext support is not an option. Rewriting gajim-remote in C is kind of solution, but IMHO it is not worth.

[Marco d'Itri <md@…>]

I disagree. Removing gettext support should be an option since this

program is designed to be generally run by scripts. The problem does not appear to be dbus latency, it can be easily verified that the program takes almost the same time when run with no options and when a trivial operation like list_accounts is requested.

[asterix]

removing the gettext support doesn't help:

without gettext support:

 $ time ./gajim-remote.py get_status
 online

 real    0m0.485s
 user    0m0.414s
 sys     0m0.029s

with gettext support:

 $ time ./gajim-remote.py2 get_status
 online

 real    0m0.514s
 user    0m0.427s
 sys     0m0.038s

[dottedmag@…]

Things become more interesting:

• /usr/bin/gajim-remote (shell wrapper): ~0.6 seconds
• /usr/share/gajim/src/gajim-remote.py (shell wrapper): ~0.33 seconds
• python2.4 gajim-remote.py: ~0.3 seconds

[nk]

ok I remove the shell wrapper. we don't care about -OO here because the

time we execute is short and better have it faster executed and see this ticket closed. [6979]