[Libosinfo] [RFC PATCH 0/5] various optimizations
Christophe Fergeau
cfergeau at redhat.com
Tue Jun 3 15:07:47 UTC 2014
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.
Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20140603/cd05430f/attachment.sig>
More information about the Libosinfo
mailing list