From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Daniel Berlin , gdb-patches@sources.redhat.com, Andrew Cagney , Jim Blandy Subject: Re: PATCH: fail to improve psymtab memory consumption Date: Tue, 24 Jul 2001 09:16:00 -0000 Message-id: <1010724161525.ZM20208@ocotillo.lan> References: <20010720212013.7DA695E9D8@zwingli.cygnus.com> <87lmljdz4g.fsf@cgsoftware.com> <87d76uerh8.fsf@cgsoftware.com> <3B5CD3B6.9060106@cygnus.com> <87zo9uaow2.fsf@cgsoftware.com> X-SW-Source: 2001-07/msg00597.html On Jul 24, 1:15am, Daniel Berlin wrote: > If you look at the code, you'll note this is a perfectly fair > benchmark, since i'm not pulling any tricks, just using a different > method of getting a memory buffer for a part of a section (With mmap, > it mmap's it, without it, it fread's it). I've always been a fan of mmap(). As Dan has pointed out, there can be several different performance wins (faster, uses less memory) associated with using it. However, one of the problems with mmap() is that it's not terribly portable. Most unices these days will have it, but some might have buggy implementations or take slightly different sets of options. Also, those systems which don't have mmap frequently have something comparable. The point that I'm driving towards is that if we're going to use mmap(), I think it would be best if we provide a layer above it so that all of the nasty "#ifdef HAVE_MMAP" baggage can be hidden away in one place. This layer will attempt to use mmap() or equivalent facilities, but failing that, it'll simply read() into a suitably sized buffer... Kevin