qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 17/21] qapi: Drop unused non-strict qobject inpu


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 17/21] qapi: Drop unused non-strict qobject input visitor
Date: Mon, 27 Feb 2017 06:46:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 02/24/2017 09:02 AM, Markus Armbruster wrote:
>> Paolo Bonzini <address@hidden> writes:
>> 
>>> On 23/02/2017 22:45, Markus Armbruster wrote:
>>>> The split between tests/test-qobject-input-visitor.c and
>>>> tests/test-qobject-input-strict.c now makes less sense than ever.  The
>>>> next commit will take care of that.
>>>
>>> I'm actually adding a use for non-strict visitors (and one that makes
>>> sense IMHO, with comments, testcases and all that :)).  See
>>> https://www.mail-archive.com/address@hidden/msg432069.html.
>> 
>> I replied.
>
> Hmm. Right now, we implement strict checking by populating a hash table
> in parallel to the QObject being visited, then checking if it gets
> emptied.  I wonder if it would be any simpler to clone the QObject and
> then remove keys, rather than tracking a separate hash table.  In fact,
> you could then turn strict checking into an after-the-fact item:
> creating the visitor passes in a QObject, then after the visit you check
> whether the QObject has been emptied.  But that's not something that has
> to be solved for 2.9.

Only dictionaries need to be cloned, everything else can be shared.

But cloning is still slow.

If QDict was an association list rather than an array, we could use a
bit vector to record visits.

Association list could well be better anyway.  I suspect most QDicts
have few keys.  Measurements needed to confirm.

>>> For what it's worth, however, I believe that even non-strict visits
>>> should detect unvisited list tails.
>> 
>> Bit of an asymmetry.  Not sure it matters, because to not visit list
>> tails, you have to put in some effort.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]