From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Berlin Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: PATCH: fail to improve psymtab memory consumption Date: Mon, 23 Jul 2001 20:36:00 -0000 Message-id: <3B5CD3B6.9060106@cygnus.com> References: <20010720212013.7DA695E9D8@zwingli.cygnus.com> <87lmljdz4g.fsf@cgsoftware.com> <87d76uerh8.fsf@cgsoftware.com> X-SW-Source: 2001-07/msg00588.html >>> I actually use mmap when possible, but that's for speed, rather than >>> memory savings. > >> >> Is it really faster? > > Yes, because it saves buffer copying (I think, it's 2am, which is > about the time i usually say something stupid, so feel free to smack > me around if i'm wrong) > (You don't have to dandy about copying buffers into the right > place. With an mmap'd area, it's already *in* the right place.) > > > Nathan myers confirms my suspicion, as well. > > http://pgsql.profnet.pl/mhonarc/pgsql-hackers/2001-05/msg01233.html > " > Using mmap() in place of disk read() almost always results in enough > performance improvement to make doing so worth a lot of disruption." > " Does this require serial or random file i/o? > Everything i can pull up on google says mmap is so much faster than > malloc+fread that it's not even funny, which means it's not just that > it feels faster. On a 100 meg debug info file, you can easily notice > the difference. What the heck. I'll think out loud. The dwarf2 sections are parsed serially, correct? That means either: o the entire section is read in (a large slow file cache thrashing copy) and then parse that buffer o the section is mmap'd - gdb's memory image grows by a large amount o the section is read, bit by bit, on demand using FILE and the hosts buffer cache. Some OS's even implement this as a mmap(). I don't know but back in the good old days CPU's and disks were vaguely comparable. How a days, the disks are the same speed but the CPU's are fasater. Simple FILE I/O could prove faster than you're expecting. Andrew