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
next prev parent 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