Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site lanl-a.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!dual!amd!fortune!hpda!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!philabs!cmcl2!lanl-a!jlg
From: jlg@lanl-a.UUCP
Newsgroups: net.lang
Subject: Slow Fortran I/O
Message-ID: <9625@lanl-a.UUCP>
Date: Wed, 27-Jun-84 20:41:21 EDT
Article-I.D.: lanl-a.9625
Posted: Wed Jun 27 20:41:21 1984
Date-Received: Fri, 13-Jul-84 23:41:01 EDT
Organization: Los Alamos National Laboratory
Lines: 17


>I have no complaint with FORTRAN's number-crunching abilities, but when it
>comes to I/O the language is a big loss.  Just recently, on our RT-11 V5.1
>system, we replaced one output subroutine in a graphics library which did its
>I/O with a FORTRAN WRITE with the equivalent subroutine using RT-11 Syslib I/O.
>This resulted in a speedup of something like 600%.  The net result was that the
>Prof. in charge bitched us out for not having done it 2 years ago, since it
>only took 5 minutes to make the change.

This isn't Fortran's fault, it's the I/O library!  I'm not surprised either
since the VMS I/O library is VERY slow.  There is no good reason for Fortran
I/O to be any slower than direct system calls (except for a small ammount
of overhead related to library table maintenance).  For some reason, DEC
chose to put a whole extra level of complexity between Fortran and the
system (called 'Record Manager' on VMS) which is as slow as molasses.

DON'T BLAME THE LANGUAGE FOR AN IMPLEMENTATION DEFECT!!