From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29085 invoked by alias); 21 Sep 2006 20:54:55 -0000 Received: (qmail 29076 invoked by uid 22791); 21 Sep 2006 20:54:54 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Sep 2006 20:54:51 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 4F1F626C72; Thu, 21 Sep 2006 13:54:50 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08128-05-21; Thu, 21 Sep 2006 13:54:49 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 5253C26C67; Thu, 21 Sep 2006 13:54:49 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Sep 2006 20:55:43 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 21 Sep 2006 13:54:48 -0700 Subject: Re: [commit] Run length encoding for gdbserver From: Michael Snyder To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org In-Reply-To: <20060921161239.GA27629@nevyn.them.org> References: <20060921161239.GA27629@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Sep 2006 20:54:00 -0000 Message-Id: <1158872088.22863.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00132.txt.bz2 On Thu, 2006-09-21 at 12:12 -0400, Daniel Jacobowitz wrote: > The remote protocol supports a simple run length encoding mechanism (in only > one direction - from the stub to the client). This patch implements it in > gdbserver. It doesn't make a huge difference to overall performance, but > can reduce the amount of data sent in some cases by 50%. This should be a significant gain for libthread_db debugging, where gdb does a lot of large memory reads behind the scenes. For stack traces it may not make that much difference, since those reads are usually small. Does it work for register packets too? > > I realize I didn't leave any room for the equivalent operation in > the new binary transfer packets in the direction from the client to > the stub, e.g. for downloading. I don't think this is a big deal. > > Tested x86_64-pc-linux-gnu and checked in. >