From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15502 invoked by alias); 22 Nov 2002 04:51:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15495 invoked from network); 22 Nov 2002 04:51:08 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Nov 2002 04:51:08 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7F9323E4B; Thu, 21 Nov 2002 23:51:01 -0500 (EST) Message-ID: <3DDDB7B5.2070809@redhat.com> Date: Thu, 21 Nov 2002 20:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH/RFC: Bring lin-lwp performance back to the real world References: <20021122041123.GA21389@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00535.txt.bz2 > - It's such a wonderful bandaid that a lot of the badly needed > cleanups may lose momentum. ``Don't you worry about that'' :-) A back of envelope calculation shows: > Plucking a ``random'' memory location out of thin air: > > cagney@torrens$ grep 0x40040ea0 gdb.strace | grep ptrace | wc -l > 7038 For <160 stops, GDB fetched a thread-db buffer 7000 times. So, GDB is fetching an identical buffer 7000/160 ~= 50 times for every stop! > cagney@torrens$ expr 7038 \* 250 > 1759500 250? I happen to know that the buffer is ~1000 bytes long which gives us 250 (1000/sizeof(long) ptrace() calls for every buffer transfer. The patch addresses the second problem, but not the first. While it releaves a bit of steam, there is still plenty of oportunity to further ramp up the performance by several more orders of magnitude. (BTW, this sort of brain-deadness on the part of GDB explains why other minor performance tweeks had zero benefit :-) ---- Note that the other /proc trickery is in linux-proc.c. Should this be there? Andrew