From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJydn-00052B-OO for qemu-devel@nongnu.org; Tue, 28 Jul 2015 02:45:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJydi-0006As-ID for qemu-devel@nongnu.org; Tue, 28 Jul 2015 02:45:31 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:19445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJydi-0006Aj-Cu for qemu-devel@nongnu.org; Tue, 28 Jul 2015 02:45:26 -0400 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NS600CE8QRNH400@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 28 Jul 2015 07:45:23 +0100 (BST) From: Pavel Fedin References: <507c11db2c97eef33de0e4f7168076d5c39f0867.1436866326.git.p.fedin@samsung.com> <87r3ntzra9.fsf@blackfin.pond.sub.org> <003201d0c879$8fced800$af6c8800$@samsung.com> <55B646CD.8010808@suse.de> <55B64900.6020008@redhat.com> <007201d0c87f$9b3e5660$d1bb0320$@samsung.com> <55B64CC2.6000307@redhat.com> In-reply-to: <55B64CC2.6000307@redhat.com> Date: Tue, 28 Jul 2015 09:45:22 +0300 Message-id: <00a901d0c900$faa98120$effc8360$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH v4 2/2] QOM: object_property_add() performance improvement List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Paolo Bonzini' , =?utf-8?Q?'Andreas_F=C3=A4rber'?= , 'Markus Armbruster' Cc: qemu-devel@nongnu.org > > Also, i thought that there could be > > some hard to notice problems, when, for example, we first add > > unnamed-gpio-in[0...1023], then add another 1024 pins, where count > > again goes from 0 to 1023. And we would get collision and failure, > > unless we know, that we already have 1024 objects with this name. >=20 > But IIUC qdev_init_gpio_in/out (the non-named variants) should only be > called once. So if it breaks it's a feature. Ok ok ok... I can try to reengineer this and see what happens. If it works fine, = will such rework be accepted? [*] expansion would still be slow, but we = could deprecate it. I have just done a search of "[*]" across all *.c files, and here is = what i came up with: 1. memory_region_init() 2. xlnx_zynqmp_init() 3. qdev_init_gpio_in_named() 4. qdev_init_gpio_out_named() 5. qdev_connect_gpio_out_named() 6. spapr_dr_connector_new() Cases 2, 3, 4 can be reengineered for sure. The rest - i don't know, = however perhaps they are not common cases. I think (1) could also be = problematic. How many regions with the same name can we have? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia