david at fubar.dk
Thu Oct 27 08:51:21 PDT 2005
On Wed, 2005-10-26 at 17:35 +0100, Richard Hughes wrote:
> How "expensive" is a hal key read/write? If I were doing 20 "reads" a
> minute, is that too much? Should I bother to cache anything?
I think it's more about design. It's like this I think: In a
well-designed program you sorta want your own abstractions, e.g. g-p-m
would have a process-wide data structure that conveniently tells
everything about system-status - optimized for GUI usage.. Such as
/* very simplified data structure */
and on startup you just fill it in and you update it on receiving events
from HAL. Hence, no method call overhead required.
Whether this is a good idea or not... I'm not really sure. But that is
the way that I would have written e.g. g-p-m. But see below.
> I guess find_by_capability and friends are more expensive. Knowledge
I think the main problem with calling into the HAL daemon is more a
problem of latency and less of the actual cost of the operation... and,
for the record... Cornelia been working on fixing some O(n) and O(n^2)
bugs we have - ideally we can get most operations down to O(1).
As you may know libhal is already prepared to do caching - all we need
is to implement it . So I guess with caching enabled in libhal you
might very well be "lazy" and not cache anything :-). Of course, I kinda
want people to use D-BUS bindings - perhaps one day we'll have a nice
glib based libhal (with caching)... a nice Mono one (with caching)...
Java, Qt, Python and so on.. Wouldn't that make more sense?
 : We probably want a new method to retrieve all devices and all
properties in a single go such that we only do 1 or 2 method calls into
HAL at startup... Everything else just relies on D-BUS signals.
More information about the hal