Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!QZCOM.MAILNET!W._Michael_Terenyi
From: W._Michael_Terenyi@QZCOM.MAILNET
Newsgroups: mod.computers.vax
Subject: Section Files
Message-ID: <207119@QZCOM>
Date: Tue, 14-Oct-86 06:51:23 EDT
Article-I.D.: QZCOM.207119
Posted: Tue Oct 14 06:51:23 1986
Date-Received: Tue, 14-Oct-86 17:44:41 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: W._Michael_Terenyi%QZCOM.MAILNET@MIT-MULTICS.ARPA, INFO-VAX_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
Organization: The ARPA Internet
Lines: 26
Approved: info-vax@sri-kl.arpa


>  Faced with a closely-related problem (TeX DVI files and a PASCAL
>  DVI-to-Impress program), I avoided the issue. I wrote modules that
>  replaced the PASCAL I/O calls.  These were FORTRAN (yes FORTRAN)
>  subroutines which mapped the DVI file as a section, and then
>  handled it as a simple vector of bytes along with a pointer to
>  the current location.
>
>  I realize it may sound complicated, but the system services needed
>  to map the file aren't really very tough.  Your source (512 byte,
>  fixed length, unformatted data) is an easy target to map to since
>  # of records <--> number of pages, and there should be nothing in
>  the file that isn't part of the byte stream.  I think you'll find
>  it significantly faster than ASCIIfying the DVI and then back-
>  converting to binary.

Although this solution seems to be elegant it has to be pointed out
that all I/O of the section file is processed through the secondary
caches (modified and free list) which has a severe impact on the
overall performance due to the increased paging rates.

Michael.