On 04/28/2009 05:13 PM, Gerrit Slomma wrote:
Cole Robinson schrieb:
(...)
To test the performance impact, I used a simple python script:
import libvirt conn = libvirt.open("qemu:///system") for i in range(0, 30): conn.getCapabilities()
The time difference was on average .02 seconds slower, which I think is negligible.
If at somepoint in the future, capabilities generation becomes smarter (searching PATH emulators, scraping device list output, etc.) it might be worth re-checking the time impact. But for now it doesn't seem to be an issue.
Thanks, Cole
------------------------------------------------------------------------
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
.02 seconds slower compared to what time? Without a given base this result doesn't say much. It wouldn't matter if the execution-time was 3600 seconds prior to the change but would be a realt bottleneck if it was 0.01 seconds prior to the change.
The results were around .4 seconds real time. I didn't think that info was particularly relevant in this case though, since the python script is fetching the capabilities 30 times. Rereading my original email again, I was pretty unclear that the .02 time difference was for calling capabilities all 30 times, so the real impact would only be .02/30 = .00067 seconds per capabilities call, which is negligible no matter what the % slow down.
I know a virsh capabilities is not that slow, but i haven't clocked it up to now but have done so now that i have read your post and got this on my machine:
rr016# time virsh capabilities (...) real 0m0.005s user 0m0.001s sys 0m0.002s
Just calling virsh capabilities isn't the best metric, since there will be overhead in driver opening, possibly authentication, actually printing the result, etc. Not that my method is perfect either, but incurs less overhead than virsh. Thanks, Cole