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 Disabling helper-message receiving of uim-pref without above manual control is better solution.
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.