Expensiveness..

[David Zeuthen]

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 */
 struct {
   bool have_batteries;
   bool have_ups;
   bool battery_is_charging;
   int num_seconds_remaining;
 } SystemState;

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
> appreciated.

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 [1]. 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?

/me shrugs

Cheers,
David

[1] : 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.