Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@cgsoftware.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Daniel Berlin <dan@cgsoftware.com>,
	gdb-patches@sources.redhat.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: PATCH: fail to improve psymtab memory consumption
Date: Tue, 24 Jul 2001 09:47:00 -0000	[thread overview]
Message-ID: <87n15ugtph.fsf@cgsoftware.com> (raw)
In-Reply-To: <3B5D85C3.1000104@cygnus.com>

Andrew Cagney <ac131313@cygnus.com> writes:

>>> Does this require serial or random file i/o?
>> ... you could make fread use mmap
>> in special cases, but they don't happen enough in practice to make
>> fread fast enough to beat mmap.
> 
> 
> It may not happen enough to ``beat mmap'', it certainly happens enough
> to justify the implementation of FILE using V/M based schema.
Err, what?
You must not have looked at most pieces of software that access disk
these days. Most use mmap when possible.
> 
> Anyway, that isn't the objective.  The objective is to get the dwarf2
> reader clean simple and pragmatically fast.  Fast, at all cost, is
> like micro-optomizing using STREQ() macros.

Which i'm opposed to completely, and you know this (I replaced quite a
few when a lot of STREQ->strcmp_iw changes went in, instead of
STREQ->STREQ_IW)

Comparing using MMAP to micro-optimizing is trivializing it in the extreme.
If you really think it's a micro optimization, once again, I invite
you to *try* it.

>If you think there should
> be a mmap implementation then abstract it out so that dwarf2 uses it
> rather than contains it.

It does.
If configure says we have MMAP, we use MMAP.

What's the problem?
Where do you think this abstraction should take place? BFD?

> 
> If you think there should be MMAP, then get it added to BFD where all
> readers will benefit, not just DWARF2.

This is tricky, because of the hell that is BFD.
Apple's tried it, i've tried it, etc.
Because of hacks and kludges for in-memory stuff in BFD, it breaks
things.

>

> 
> 	Andrew

-- 
"I like to go to art museums and name the untitled paintings...
Boy With Pail...  Kitten On Fire.
"-Steven Wright


  reply	other threads:[~2001-07-24  9:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010720212013.7DA695E9D8@zwingli.cygnus.com>
2001-07-20 15:17 ` Daniel Berlin
2001-07-20 22:22   ` Jim Blandy
2001-07-20 23:17     ` Daniel Berlin
2001-07-21  8:50       ` Jim Blandy
2001-07-23 20:36       ` Andrew Cagney
2001-07-23 22:15         ` Daniel Berlin
2001-07-24  7:49           ` Andrew Cagney
2001-07-24  9:47             ` Daniel Berlin [this message]
2001-07-24  9:16           ` Kevin Buettner
2001-07-24  9:35             ` Christopher Faylor
2001-07-24 10:13               ` Frank Ch. Eigler
2001-07-24 10:57                 ` Christopher Faylor

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=87n15ugtph.fsf@cgsoftware.com \
    --to=dan@cgsoftware.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@cygnus.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox