Bug 3620

First of all, we need to keep uim context in the text widgets of uim-pref
because customization of string-list will be needed in the future, as you
noted in skk.scm.  So just disabling uim is not preferable.

And it seems that removal of receiving helper message in uim-pref is difficult
since each text widget in uim-pref has normal uim context.

So as a send best way to solve the slow custom update, I can think of
the way which I noted on anthy-dev 1973, dividing helper client type
with normal one and tool bar one, and make helper-server not to send
'prop_lable/list_update' to normal clients.

Just my 2 cent.

Oops typo. s/a send best/a second best/.

Change hardware and OS as I confirmed the slowness on MacOSX.

Without special setting, pressing apply button consumes about 5 seconds on my
machine. Surely it's slow.

I guessed bottleneck was the transfer of all custom variables. Therefore, I
created new helper message which doesn't send any values. (It only notifies
to other processes as 'setting was changed'.)

Instead of transferring all custom variables, we can reread all custom variables
from ~/.uim.d/. This is not an efficient way, but easy to implement and faster
than prop_update_custom.

Now pressing apply button became faster than twice.

  About 2 seconds (Pentium M 800MHz)
  Less than 1 second (Pentium M 1800MHz)

Still I'm not comfortable, but I can have patience with this speed.

I committed new code in revision 1159 and 1160.

TODO: check mtime of each cofig files. If not updated, then it need not to
reread. This will make faster than now.

Sorry, I was wrong a bit. I committed in revision 1160 and 1161.

(In reply to comment #3)
> Without special setting, pressing apply button consumes about 5 seconds on my
> machine. Surely it's slow.
> 
> I guessed bottleneck was the transfer of all custom variables.

No. See the fact I wrote in comment #0

> The operation takes about 5 seconds on my machine.
> Primary factor of the problem is unwanted loopback helper messages. Disabling
> uim for uim-pref resolves this problem.
> 
> For example, following uim-pref invocation without uim-xim disables uim. It
> takes about 1 second for the operation.
> 
> GTK_IM_MODULE=xim uim-pref-gtk

It reduced 80% of the time consumption by closing only one socket which sends
messages from helper-server to the uim context of uim-pref. It's the primary factor.

The message bus facility you suggested will resolve it without disabling the uim
immodule as avobe.

Of cource further performance improvement such as you are developing on now is
valuable.
But you should be aware of the verified fact when doing it.

Moved to https://github.com/uim/uim/issues/5