On Thu, 2008-10-09 at 18:01 +0100, Daniel P. Berrange wrote: > On Thu, Oct 09, 2008 at 12:25:18PM -0400, David Lively wrote: > > Hi Daniel - > > I'm implementing virNodeDeviceDef, as suggested, but I just noticed > > something that really bothers me. In a nutshell, it's that the current > > implementation of this scheme unnecessarily increases the (time) > > complexity of O(1) operations to O(n). > > For example, take virDomainGetXMLDesc(). One would think dumping the > > XML descriptor for a domain object we have in hand would be O(1), but in > > fact, it's O(n) (where n is the number of domains with the same driver), > > because qemudDomainDumpXML must find the DomainObjPtr (from which it can > > get the def). I suppose this lookup could be made O(log n) if the > > domains were sorted by UUID on the list, but the fact remains that > > lookup could be eliminated entirely. > > Sure the lookup algorithm is O(n), but have you actually got real > world benchmarks showing this is the serious bottleneck? In the XML Well ... uhh ... no. :-o > dump example, the time to lookup the object is likely dwarfed by the > time to generate the XML doc, or to talk to the QEMU monitor. > IMHO, optimizing this is overkill. Worst case we can just hash on > the UUID if it ever provdes a problem. Okay, I'll buy that. And (now) I see what you mean about the differing object lifetime. ... In fact (perhaps I shouldn't be admitting this publicly), your whole public-obj/Obj scheme now finally makes sense to me! The public objs are really just a kind of handle to the private Objs, and they exist independently of one another. public objs belong to the apps, private Objs to the appropriate driver. And (now that I look at the Xen driver), I finally understand that there are stateless drivers. In fact, both the devkit and HAL node-dev drivers need to be stateful (since the device name isn't a reasonable handle for either devkit or HAL devices), so I'm creating a virNodeDeviceObj as well as a virNodeDeviceDef. Dave -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list