Re: Slow down with: 'Make "info qom-tree" show children sorted'

[David Gibson <dgibson@redhat.com>]

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

On Tue, 07 Jul 2020 14:00:06 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > On 07/07/20 07:33, Markus Armbruster wrote:  
> >> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> >>   
> >>> On 7/7/20 6:45 AM, Thomas Huth wrote:  
> >>>> On 27/05/2020 10.47, Markus Armbruster wrote:  
> >>>>> "info qom-tree" prints children in unstable order.  This is a pain
> >>>>> when diffing output for different versions to find change.  Print it
> >>>>> sorted.
> >>>>>
> >>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> >>>>> ---
> >>>>>  qom/qom-hmp-cmds.c | 24 ++++++++++++++++--------
> >>>>>  1 file changed, 16 insertions(+), 8 deletions(-)  
> >>>>
> >>>>  Hi Markus,
> >>>>
> >>>> this patch causes a slow down of the qtests which becomes quite massive
> >>>> when e.g. using the ppc64 and thourough testing. When I'm running
> >>>>
> >>>> QTEST_QEMU_BINARY="ppc64-softmmu/qemu-system-ppc64" time \
> >>>> ./tests/qtest/device-introspect-test -m slow | tail -n 10
> >>>>
> >>>> the test runs for ca. 6m40s here before the patch got applied, and for
> >>>> mor than 20 minutes after the patch got applied!  
> >> 
> >> That's surprising.  
> >
> > It's a bit surprising indeed, but on the other hand using
> > g_queue_insert_sorted results in a quadratic loop.  
> 
> The surprising part is that n turns out to be large enough for n^2 to
> matter *that* much.

Is this another consequence of the ludicrous number of QOM objects we
create for LMB DRCs (one for every 256MiB of guest RAM)?  Avoiding that
is on my list.  Though avoiding a n^2 behaviour here is probably a good
idea anyway.

-- 
David Gibson <dgibson@redhat.com>
Principal Software Engineer, Virtualization, Red Hat

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