[PATCH 0/8] Various large optimisations

Doug Klima cardoe at gentoo.org
Mon Nov 19 08:55:08 PST 2007


Rob Taylor wrote:
> Here is a sequence of patches that optimise HAL's startup time and
> memory usage.
>
> They can be split down into 5 main parts:
>
>  1) Use gslice for HalProperty and HotplugEvent. This gives us better
> memory locality for these commonly used structures
>
>  2) Only generate HotplugEvents during coldplug when they are actually
> needed, and process them as soon as they are queued. This removes a lot
> of the huge (7M on my machine) memory usage on coldplug
>
>  3) Use GQuarks for property names - this gives a modest cut in
> footprint and improves locality.
>
>  4) Allow hotplug events to process in parallel. This intruduces into
> HAL a similar parallel event processing method as udev. Along with 2),
> this removes the coldplug memory peak almost entirely (Cutting down to
> 350K on my intel hardware and about 150K on an N800)
>
>  5) Add the ability in HalDeviceStore to index given properties by
> value. Profiling showed that about 20% of coldplug time was spend in
>  hal_device_store_match_key_value_string to look up devices by
> sysfs_path. This generic patch cuts each lookup to a couple of hash
> table lookups, versus n strcmps.
>
>  Options and feedback most welcome!
>
>  Thanks,
>  Rob Taylor
>   
I like the ideas, looks good.

1) Great. g_slice has already shown in a use case similar to HalProperty
and HotplugEvent it provides a benefit. Only downside is that our glib
requirement moves to 2.10, but I don't think that's too much to ask for
in todays world. It even appears to be a code simplification since we
don't need to handle pools of memory anymore.

2) This has been discussed before and is a welcome piece of code. Looks
like you've removed the sysfs path lookup and are reading it straight
from udevinfo which in an of itself is a plus.

3) As I understand it to do the property matching, glib already converts
data to gquarks so we're basically removing the constant conversion from
happening.

4) It took a bit to hammer out all the issues with parallel plugging in
udev. I'm sure we're going to see some regressions in HAL regarding the
ordering as well. I'd say this one is a bit more experimental.

5) Looks great.


More information about the hal mailing list