From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28162 invoked by alias); 21 Nov 2008 07:44:56 -0000 Received: (qmail 20240 invoked by uid 48); 21 Nov 2008 07:43:30 -0000 Date: Fri, 21 Nov 2008 07:44:00 -0000 Message-ID: <20081121074330.20239.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jb at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg01763.txt.bz2 ------- Comment #8 from jb at gcc dot gnu dot org 2008-11-21 07:43 ------- (In reply to comment #7) > From some experiments I have done, we can make substantial improvement by > streamlining next_char. What I have in mind is reading a whole or partial > block of a file and returning a pointer. Then advancing forward next char is a > matter of incrementing the pointer,or back as in unget_char, decrementing the > pointer. > > push_char then becomes simply an assignment. This approach would get rid of > all the function calls and and do the necessary manipulations with pointer ops > and assignments. It will take some careful rework, but I think it can be done. > > Janne, is this what you had in mind? are you doing this? Essentially yes. I have converted the read side to use the fbuf_* machinery as well, and I have a fbuf_read(gfc_unit *, size_t *) function that fills the fbuf buffer with a specified number of bytes (by calling sread()) and then returns a pointer to the first element (the maximum size to iterate to is returned via the pointer argument). Well, that's the general idea, I still have some nasty bugs to figure out. And as I said, I think the changes are invasive enough that even if I'd get it done soon, I don't think it's 4.4 material. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754