On Thu, Apr 11, 2013 at 11:03 PM, Eric Blake <eblake(a)redhat.com> 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