Expensiveness..

Richard Hughes hughsient at gmail.com
Sun Oct 30 10:13:52 PST 2005


On Thu, 2005-10-27 at 11:51 -0400, David Zeuthen wrote:
> 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;

This is sortof how I have done it in g-p-m, except with one struct per
device. There *are* changes in the works for g-p-m soon.

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

Cool.

> 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?

Eigh? You said libhal was depreciated and a glib version of libhal was
off the cards. I've been carrying a (somewhat incomplete) glib libhal
implementation in g-p-m for a few months now.

Richard.



More information about the hal mailing list