[Libosinfo] [RFC PATCH 0/5] various optimizations

Giuseppe Scrivano gscrivan at redhat.com
Tue Jun 3 16:52:47 UTC 2014


Christophe Fergeau <cfergeau at redhat.com> writes:

> On Tue, Jun 03, 2014 at 03:57:25PM +0100, Daniel P. Berrange wrote:
>> On Tue, Jun 03, 2014 at 04:51:14PM +0200, Giuseppe Scrivano wrote:
>> > "Daniel P. Berrange" <berrange at redhat.com> writes:
>> > 
>> > > I'd suggest using oprofile or sysprof to collect data on exactly
>> > > where our cputime is disappearing to before trying to optimize
>> > > further.
>> > 
>> > 
>> > I've seen that creating and accessing many gobjects, as this chunk of
>> > code in osinfo_loader.c does, takes a lot of cputime:
>> > 
>> >                 OsinfoDevice *dev = osinfo_loader_get_device(loader, id);
>> >                 osinfo_entity_set_param(OSINFO_ENTITY(dev),
>> >                                         OSINFO_DEVICE_PROP_VENDOR_ID,
>> >                                         vendor_id);
>> >                 osinfo_entity_set_param(OSINFO_ENTITY(dev),
>> >                                         OSINFO_DEVICE_PROP_VENDOR,
>> >                                         vendor);
>> >                 osinfo_entity_set_param(OSINFO_ENTITY(dev),
>> >                                         OSINFO_DEVICE_PROP_PRODUCT_ID,
>> >                                         device_id);
>> >                 osinfo_entity_set_param(OSINFO_ENTITY(dev),
>> >                                         OSINFO_DEVICE_PROP_PRODUCT,
>> >                                         device);
>> >                 osinfo_entity_set_param(OSINFO_ENTITY(dev),
>> >                                         OSINFO_DEVICE_PROP_BUS_TYPE,
>> >                                         busType);
>> 
>> So that basically comes down to the performance of the hash
>> table inserts. I wonder if we could make use of GQuark and/or
>> g_intern_string so that the hash table lookup can do a straight
>> pointer or int comparison, instead of strcmp. }?
>
> The call to osinfo_loader_get_device() can also hide a g_object_new(),
> which can be heavy.

indeed, g_object_new seems to be very slow.  I will try to play with
what Daniel suggested and see if it makes any difference.

I am going to send a v2 soon with all the suggested fixes for this
series.

Thanks,
Giuseppe




More information about the Libosinfo mailing list