NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/postscri/5666

Text File | 1992-11-23 | 4.5 KB | 96 lines

Newsgroups: comp.lang.postscript
Path: sparky!uunet!nntp1.radiomail.net!fernwood!trilithon!henry
From: [e-mail] (Henry McGilton)
Subject: Re: VM questions in Blue Book
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Trilithon Software
References: <[e-mail]>
Date: Mon, 23 Nov 1992 05:55:50 GMT
Lines: 84

In article <[e-mail]> [e-mail] (zzang)
writes:
    *  I am reading the Blue Book, and I like it very much. but
    *  it is hard for me to understand the virtual memory.  what
    *  is the virtual memory, is it something about the disk spaces
    *  used by the program to extend the RAM capability?
    ``Virtual Memory'' as defined in Adobe books relative to
PostScript, has nothing to do with ``real'' ``virtual memory''
as you would understand using some kind of backing store to provide
the illusion of large amounts of primary memory.
    If you have a disk attached to your printing machine, it does
not contribute towards VM in printer RAM.
    ``Virtual Memory'' as defined in Adobe books refers to a large
amorphous blob of storage where so called ''composite objects''
are allocated.  There's only so much of this blob available, and
when you've used it all up, you're out of luck.  As a PostScript
programmer, you have to manage virtual memory.  When you're writing
one-off trivial PostScript programs, VM is usually no problem.
When you're writing the driver part of an application to generate
pages of PostScript, you have to be aware of what kinds of stuff
use up VM.
    In PostScript Level One, the save and restore mechanisms provide
the means to manage VM.  For document kind of systems, bracketing
each page inside a save and restore pair is a useful notion.  When
you import EPS files, bracket the EPS inside save and restore pairs.
    *  here is the example from the book:
    *  1:
    *  /localdict 1 dict def
    *  /sampleproc {
    *    localdict begin
    *        /localvariable 6 def
    *    end
    *  } def
    This example defines a local dictionary called localdict.
There is only one instance of localdict.  Every time sampleproc
is used, localdict is pushed onto the top of the dictionary stack
(with the begin operator).  A local variable called localvariable
is defined in localdict.  Then localdict is popped off the dictionary
stack (with the end operator).  So far, so good.  localdict consumes
only as much VM as is needed for a dictionary, plus one key/value
pair.  This is all the VM that localdict will consume for the life
of the PostScript job.  localdict was alocated only *once* --
outside the sampleproc procedure.
    *  2:
    *  /sampleproc {
    *    1 dict begin        %this allocates new VM each time
    *        /localvariable 6 def
    *    end
    *  } def
    This example is subtly different.  *Every Time* sampleproc gets
used, it executes two PostScript instructions (1 dict, and begin)
to allocate a one element dictionary in VM and push that dictionary
onto the top of the dictionary stack.  It then defines a variable
in that dictionary.  Then it pops that dictionary off the dictionary
stack (with the end operator).  As a matter of fact, the definition
of localvariable is irrelevant to this discussion.  What matters
is the allocation of a one element dictionary in VM *every time
sampleproc is used*.  If you do this:
    1 1 100 {
        /MyString (This Is A String) def
    } for
you will end up with 100 (unreferenced) copies of (This Is A String)
in VM.  Even though the contents of the string are the same each time,
a fresh copy of the string is allocated each time through the loop.
    *  The book says the 2nd procedure will use more memory.  but
    *  they look the same to me, I am totally confused.  could
    *  someone explain this.
    A lot of this stuff is explained in our book ``PostScript by
Example'', by Mary Campione and Henry McGilton, published by Addison
Wesley.  At one point in our book we point out the difference
between these two code fragments for working on the font directory:

    Code Fragment One                  Code Fragment Two
    ==== ======== ===                  ==== ======== ===
/JunkString 256 string def
FontDirectory {                    FontDirectory {
                                       /JunkString 256 string def
   do a bunch of stuff                 do a bunch of stuff
} forall                           } forall
    Fragment One allocates only one copy of JunkString in VM.
Fragment Two allocates a new copy of JunkString in VM every
time though the loop.

    ........  Henry