Dwarves Archive on lore.kernel.org
 help / color / Atom feed
From: Arnaldo Carvalho de Melo <acme-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Ilpo Järvinen" <ilpo.jarvinen-pxSi+dnQzZMxHbG02/KK1g@public.gmane.org>
Cc: dwarves-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: speedup in tag lookup using hash tables
Date: Tue, 12 Feb 2008 10:50:37 -0200
Message-ID: <20080212125037.GE4157@ghostprotocols.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0802121301180.31652-Y/UOj9v5BLQhZigby9b+C6cUovnZ0M2TMR2xtNvyitY@public.gmane.org>

Em Tue, Feb 12, 2008 at 01:24:44PM +0200, Ilpo Järvinen escreveu:
> On Mon, 11 Feb 2008, Arnaldo Carvalho de Melo wrote:
> 
> > 	Today I optimized the dwarves a bit by using a per object file
> > hash table for tag lookup, it yelded almost 50% speedup on pahole when
> > running on a vmlinux file :-)
> >
> > 	codiff doesn't makes that much tag lookups, so we didn't got
> > much improvements there,
> 
> Because I had to do these file by file anyway, I ended up using modified 
> timestamps in my scripts to avoid loading .o files altogether when one 
> wasn't recompiled. It helped some.

This reminds me that I have to add support comparing build trees, so
that we can use 'make O=old' to build a baseline and then 'make O=new',
using ccache to reuse the old (or simply copying old to new) and then
process file after file, combining the results for tree wide
comparisions/statistics.
 
> > but I'm doing experiments on dead tag elimination
> > that probably will help a lot there, but for that I have first to grok
> > Ulrich Drepper's libdisasm to find out what are the tags that are really
> > used by looking at accesses to register indexed memory areas that use as
> > a base pointer what is in local/global variables and function
> > parameters.
> >
> > 	This also will provide the basis for detecting access patterns
> > that will ultimatelly allow libdwarves_reorganize to do struct
> > reorganizations to improve locality of reference, etc.
> 
> This sounds nice, I was thinking something similar earlier but would have 
> tried to do that with some kind of source analysis.

That is possible too, and indeed I did experiments in the past with
sparse, the library used by the kernel checker (make C=[12]), but I
think that tapping into the readily available debuginfo packages, not
just for the kernel, looking at the end, object file, result is better.
 
> > 	Please take a look at v1.6 that I pushed today and tell me your
> > impressions.
> 
> Thanks, I'll check that later on. My bruteforce inline remover run over 
> all include/ stuff just finished yesterday after ~1.5 days (ie. ~5800 
> inlines compile tested on ~90 slaves, next time I'll have to plug ccache 
> into that site-specific distribute thing I use to speed it up a lot :-)), 
> I'll post the results later on to lkml+netdev with some patches and 
> thoughts, the winner seems to be this beauty :-) :
>    -110805  869 funcs, 198 +, 111003 -, diff: -110805 --- skb_put
> ...And 22 other are in 10000+ category and 235 1kB+ (some overlap 
> exists due to __-funcs). What still remains to do are the non-include/ 
> headers which might reveal some candies too.

Excellent! Some people at some point noted that while the dwarves are
useful for showing the problems, people actually had to follow up with
patches to solve the problems, I'm very happy that you are doing just
that, thanks a lot for that.

- Arnaldo

  parent reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-12  0:03 Arnaldo Carvalho de Melo
     [not found] ` <20080212000310.GB4157-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
2008-02-12 11:24   ` Ilpo Järvinen
     [not found]     ` <Pine.LNX.4.64.0802121301180.31652-Y/UOj9v5BLQhZigby9b+C6cUovnZ0M2TMR2xtNvyitY@public.gmane.org>
2008-02-12 12:50       ` Arnaldo Carvalho de Melo [this message]
     [not found]         ` <20080212125037.GE4157-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
2008-02-12 13:24           ` Ilpo Järvinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080212125037.GE4157@ghostprotocols.net \
    --to=acme-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=dwarves-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ilpo.jarvinen-pxSi+dnQzZMxHbG02/KK1g@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Dwarves Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dwarves/0 dwarves/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dwarves dwarves/ https://lore.kernel.org/dwarves \
		dwarves@vger.kernel.org
	public-inbox-index dwarves

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.dwarves


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git