Performance question - retrieving and sending messages takes ~20 seconds

[ghost]

First things first: I use this signal-cli inside a Python program via the subprocess module. However, executing the retrieve (signal-cli -u <sender> receive [--json]) command in a bash terminal still takes ~20 seconds to complete. Can anyone explain why this is taking so long?

[exquo]

Two common causes for signal-cli's long response times are: a long java virtual machine startup time, and the lack of cryptographic entropy. To avoid the JVM startup time, run signal-cli as a daemon and use dbus to interact with it; see https://github.com/AsamK/signal-cli/wiki/DBus-service. To increase system entropy, packages like haveged can help; see #101, #108, #131.

I don't know if receive requires any entropy, so it's probably all JVM startup time in your case. What hardware are you using, out of curiosity?

[ghost]

Running signal-cli as a daemon is a good idea - thanks for that! I'll try it later today and will report back wrt. performance.

My program mainly runs on a Raspberry (3), although it also takes about the same time on my Thinkpad T14. Just for your information, it's a cool little project I'm working on, basically I create a little assistant for me. I can (1) schedule messages, which are delivered at a certain time to a certain person (mainly used as reminder for myself), (2) keep track of my sport habits, (3) regularly (i.e. every few hours) check if certain websites (blogs and forums I follow, or for example, this very thread to be notified as soon as there is a comment) have changed, and if so I'll receive a signal message. In case anyone is interested in this project, please tell me, I'll be more than happy to provide the source code (I may even publish my git repo with a GPL license).

[ghost]

After using DBUS, I can now receive messages near-instantaneous (<2 sec). Thank you very much for your help!