From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3295 invoked by alias); 27 Aug 2013 06:21:47 -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 3283 invoked by uid 89); 27 Aug 2013 06:21:46 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Aug 2013 06:21:46 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VECes-0003iv-A5 from Yao_Qi@mentor.com ; Mon, 26 Aug 2013 23:21:42 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Aug 2013 23:21:42 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.2.247.3; Mon, 26 Aug 2013 23:21:39 -0700 Message-ID: <521C452A.1000503@codesourcery.com> Date: Tue, 27 Aug 2013 06:21:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tom Tromey CC: Subject: Re: [RFC] GDB performance testing infrastructure References: <520B7F70.6070207@codesourcery.com> <87eh9mdbj1.fsf@fleche.redhat.com> In-Reply-To: <87eh9mdbj1.fsf@fleche.redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-08/txt/msg00772.txt.bz2 On 08/22/2013 04:38 AM, Tom Tromey wrote: > 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:-) Right, as we write more and more test cases, we do need more python APIs for different components in GDB. > > 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. > I am OK on this way. On each machine the performance testing is deployed, people have to find some large executables with debug info, and track the performance of GDB loading them and searching for some symbols. > 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? > No. > 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. I plan to add a new makefile target 'check-perf' to run all performance testing cases. > > 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. Agreed. In my experiments, I save test result in a python object, and print them into plain text or json format later. I'll post patches soon... -- Yao (齐尧)