Re: [Qemu-devel] [PATCH v4 5/5] update docs/qmp-full-introspection.txt

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

On 01/24/2014 04:43 AM, Paolo Bonzini wrote:
> Il 23/01/2014 15:46, Amos Kong ha scritto:
>> +The whole schema information will be returned in one go, it contains
>> +all the schema entries. It doesn't support to be filtered by type
>> +or name. Currently it takes about 4 seconds to return about 1.7M string.
>> +Management only needs to execute this command once after installing
>> +QEMU package.
>> +

But management has to call the command for every variant of the qemu
binary that it plans on driving - on a system with multiple qemu-* for
targetting multiple target types, this starts to border on unacceptably
long for libvirt.  And while libvirt might use this command to learn
about what is supported for a handful of specific commands, making
libvirt store 1.7M + additional memory for its JSON parse of that data
per qemu starts to add up fast, if libvirt were to keep that data around
for the life of libvirtd rather than just learning what it needs from
the string and discarding the string up front.  We've just made an
argument for WHY we need filtering to just a given type/command.

> 
> This is quite a lot.
> 
> Without comments, qapi-schema.json is 27k.  I'd expect the DataObject
> representation to be in the ballpark of 100-200k.
> 
> I don't understand why is it necessary to expand all the types in the
> result?

Any time a type is returned at the top level in the same query (such as
in your global query), management can look up any unexpanded type in the
same result.  I could understand expanding the results when returning
only a subset of the tree (that is, when filtering is added, asking for
a single type should give me all information about that type, including
the subtypes it references, without me having to make multiple calls to
learn about the subtypes), but even then, it might be worth having an
optional boolean flag on the query that says whether I want expansion
vs. compact results.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]