On Thu, Apr 11, 2013 at 11:03 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: [...] > No need. You are talking about the error path, the one that only hits > on the RARE case of OOM. If we are OOM, we are already hosed - what > does it matter if we take a few extra calls to a few more virCommand*() > functions before finally reporting the error to the user? All that > matters is that we are hosed gracefully (ie. that we DO report the > error, instead of crashing). > ACK. > > One more point: libvirt is generally not the bottleneck. Remember, > libvirt is the management, the thing that kicks off the long-running > tasks. But the long running tasks are separate processes. Libvirt > itself is not doing the long-running task. Therefore, shaving a few > instructions off of libvirt is generally going to have a negligible > effect on the overall performance of your usage of the virt stack. > Focus on features, not micro-optimizations, unless you can first post > benchmarks proving that libvirt is indeed the cause of a bottleneck you > are trying to optimize. > Hmmm..., i see. Let me focus on our Libvirt features, thanks. -- Thanks Harry Wei -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list