[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