From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 21942 invoked from network); 20 Oct 2022 15:57:46 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 20 Oct 2022 15:57:46 -0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by 9front; Thu Oct 20 11:56:08 -0400 2022 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E7C7E5C003F for <9front@9front.org>; Thu, 20 Oct 2022 11:56:06 -0400 (EDT) Received: from imap52 ([10.202.2.102]) by compute3.internal (MEProxy); Thu, 20 Oct 2022 11:56:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aqwari.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1666281366; x=1666367766; bh=4KxVLMxtDV Y3k3eCq0nwDihcL2EnS8K+DQNU+8G7A9o=; b=v8Qqxin018uIHVPvOkC5FLyML9 qSrJlBqj3I7gOYQwGZdgbvHX8uE0VpgO3i5x7L519afl43Gqx6SuyJhbM5tA3cLo Htx8BRZ1OJKU3M9IMMfTKupIJv2aLDfaHhczuYUFRnmZD4ertMFMWnX/EX+C9sfG jmguNvTidl3fIzo15FP+W1Y7QrZ7T1YZfDbRxmvzDpxX0BAn3qlcFQ+7cCXHOPLz cFfKfJuoNunw3sob8M2nNxKgPhxrV0XY4YXeEScvTjlTpsxn36+pBgaWzgkMj6ID vHp7qOSd+9CO8IVos/xZvwsStuoGorEizR01gAxDZlv9HdL0Grf8A+6ESaGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1666281366; x=1666367766; bh=4KxVLMxtDVY3k3eCq0nwDihcL2En S8K+DQNU+8G7A9o=; b=XIiojOqxXdG/MNkKIkqFDL0SENbflheQM+A6TUPvU0Ug etM56ILsyEBKo114UZ92ZubOeHWYAMkVDmzaDsmKLusucYQOgIRNPKH7tEwgRhjb qXDIoRe+G2bIH6QIJL3LNty6Ss240tiUIfH2HCbu75hKpXZ/oNgww+14MH58b+jp E4j6ppnaaY9xGaA7bxOAA9wq9Dln1yBcqFqZNX4wwipl40iPIdAXJNZytCrp/dAN v+z68mUmPITKPlVHab2imZ6PanquDnJcTntv0MoiWdH6K9yajhuNi2hQO/C5PJSR RhoHlehbj8p0hb6acvw2JsM3GmMP6gLO+QJBHbU8AQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeliedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfffgrvhhiugcutehrrhhohihofdcuoegurhhohihosegr qhifrghrihdrnhgvtheqnecuggftrfgrthhtvghrnhepheekheefieetudfhhefftefgtd egfeeuvdevhfehleettdehtdffgeekgeeileegnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepughrohihohesrghqfigrrhhirdhnvght X-ME-Proxy: Feedback-ID: i624b4305:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id AF3B0C60091; Thu, 20 Oct 2022 11:56:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad Mime-Version: 1.0 Message-Id: <85db2d6b-e60a-4236-9a2c-5b0b77ef99f6@app.fastmail.com> In-Reply-To: References: Date: Thu, 20 Oct 2022 11:55:45 -0400 From: "David Arroyo" To: 9front@9front.org Content-Type: text/plain List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible open-source component Subject: Re: [9front] Speeding up snoopy(8) Reply-To: 9front@9front.org Precedence: bulk On Tue, Oct 18, 2022, at 00:57, droyo@aqwari.net wrote: > total: 1150 > TEXT 00200000 > ms % sym > 360 31.3 pread > 230 20.0 pwrite > 120 10.4 nsec > 110 9.5 _filterpkt > 70 6.0 tracepkt > 60 5.2 p_filter > 60 5.2 defaultframer > 50 4.3 p_filter > 40 3.4 be2vlong > 20 1.7 read > 10 0.8 write > 10 0.8 newfilter > 10 0.8 main > ... snip ... > More generally, though, I think snoopy could be much faster if it > read multiple frames per pread() and wrote multiple records per > pwrite(). I thought about this some more, and I realize that this approach is premature at best and plain wrong at worst. Snoopy should spend as much time as possible in pread, because that is when it is depleting the queue. I should be trying to reduce the time spent in everything *except* read, and only then should I be worrying about the per-packet pread overhead. Reading multiple packets at a time would, however, reduce the number of nsec() calls. I will experiment with putting the pwrite in a separate thread, and look for small performance improvements in the other functions. I am not sure why nsec() time is so high, but I think that's a function that could perform very differently on real vs virtual hardware, so I'm hesitant to try to improve it until I get 9front running on a real machine. David