Christophe Fergeau <cfergeau@xxxxxxxxxx> 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@xxxxxxxxxx> 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 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
