From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17667 invoked by alias); 21 Aug 2013 20:39:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17652 invoked by uid 89); 21 Aug 2013 20:39:02 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 21 Aug 2013 20:39:02 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7LKd0BJ027151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 16:39:00 -0400 Received: from barimba (ovpn-113-142.phx2.redhat.com [10.3.113.142]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r7LKcwfc018265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 16:38:59 -0400 From: Tom Tromey To: Yao Qi Cc: Subject: Re: [RFC] GDB performance testing infrastructure References: <520B7F70.6070207@codesourcery.com> Date: Wed, 21 Aug 2013 20:39:00 -0000 In-Reply-To: <520B7F70.6070207@codesourcery.com> (Yao Qi's message of "Wed, 14 Aug 2013 21:00:32 +0800") Message-ID: <87eh9mdbj1.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-08/txt/msg00610.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> Here is a proposal of GDB performance testing infrastructure. Yao> We'd like to know how people think about this, especially on, Yao> 1) What performance issues this infrastructure can test or Yao> handle, Yao> 2) What does this infrastructure look like? What it can do Yao> and what it can't do. I think this looks good. I have a few questions and whatnot, nothing serious. Yao> + GDB load a python script, in which some operations are performed and Yao> performance data (time and memory usage) is collected into a file. Yao> The performance test is driven by python, because GDB has a good Yao> python binding now. We can use python too to collect performance Yao> data, process them and draw graph, which is very convenient. I wonder whether there are cases where the needed API isn't readily exposed to Python. I suppose that is motivation to add them though :-) Yao> 2. When we test the performance of GDB reading symbols in and Yao> looking for symbols, we either can fake a lot of debug Yao> information in the executable or fake a lot of `objfile', Yao> `symtab' and `symbol' in GDB. we may extend `jit.c' to add Yao> symbols on the fly. `jit.c' is able to add `objfile' and Yao> `symtab' to GDB from external reader. We can factor this part to Yao> add `objfile', `symtab', and `symbol' to GDB for the performance Yao> testing purpose. However, I may be wrong. I tend to think it is better to go through the normal symbol reading paths. The JIT code does things specially; and performance testing that may not show improvements or regressions in "ordinary" uses. Yao> * Run `single-step' with GDBserver Yao> ,---- Yao> | $ make check RUNTESTFLAGS='--target_board=native-gdbserver single-step.exp' Do you anticipate that these tests will be run by default? One concern I have is that if we generate truly large test cases, then running the test suite could become quite painful. Also, it seems that performance tests are best run on a quiet system -- so running them by default may in general not yield worthwhile data. Yao> Here is the performance data, and each row is about the time usage of Yao> handling loading and unloading a certain number of shared libraries. Yao> We can use this data to track the performance of GDB on handling Yao> shared libraries. Yao> ,---- Yao> | solib 128 in 0.53 Yao> | solib 256 in 1.94 Yao> | solib 512 in 8.31 Yao> | solib 1024 in 47.34 Yao> | solib 2048 in 384.75 Yao> `---- Perhaps the .py code can deliver Python objects to some test harness rather than just printing data free-form? Then we can emit the data in more easily manipulated forms. Tom