"Distillery" was actually the name of the original PostScript version that Glenn Reid posted to usenet in the 1980's. Here is a copy of his "release 10 of the Distillery" from 10 Mar 1989:

https://donhopkins.com/home/archive/postscript/newerstill.ps...

It was actually John Warnock's original idea, which I learned about from Owen Densmore's paper about using NeWS as a "linguistic motherboard":

https://news.ycombinator.com/item?id=28115946

>Glenn Reid wrote a PostScript partial evaluator in PostScript that optimized other PostScript drawning programs, called "The Distillery". You would send still.ps to your PostScript printer, and then send another PostScript file that drew something to the printer. The first PostScript Distillery program would then partially evaluate the second PostScript drawing program, and send back a third PostScript program, an optimized drawing program, with all the loops and conditionals unrolled, calculations and transformations pre-computed, all in the same coordinate system.

>It was originally John Warnock's idea, that Glenn implemented. And it led to Adobe Acrobat's "Distiller". Acrobat is basically PostScript without the programming language.

[...]

https://news.ycombinator.com/item?id=33827923

>Owen Densmore recounted John Warnock's idea that PostScript was actually a "linguistic motherboard". (This was part of a discussion with Owen about NeFS, which was a proposal for the next version of NFS to run a PostScript interpreter in the kernel. More about that here:)

https://news.ycombinator.com/item?id=30558915

>Glenn Reid described his classic "Grandfather Clock" metaphor to comp.lang.postscript that really opened my eyes about writing code in interpreted languages like PostScript (and JavaScript, while JIT'ed at runtime, still makes calling native code expensive), and balancing optimization with readability. With modern JavaScript/canvas, JavaScript code that calls other JavaScript code runs really fast, but calling between JavaScript and built-in code is still slow, so it's good to have the built-in code do as much as possible when you do (like rendering a long string of text at once, instead of rendering it word by word like many PostScript drivers would):

>Glenn's post in a comp.lang.postscript discussion about PostScript programming style and optimization:

https://groups.google.com/forum/#!search/%22glenn$20reid%22$...

From: Glenn Reid (Abode Systems)
Newsgroup: comp.lang.postscript
Subject: Re: An Idea to Help Make Postscript Easier to Read (and Write)
Date: 10 Sep 88 17:26:24 GMT

You people tend to forget that the PostScript language is interpreted.
It is well and good to use tools to convert to and from PostScript,
but it is not quite as "transparent" as we all might think.
I like to think of a big grandfather clock, with the pendulum swinging.
Each time pendulum swings, the PostScript interpreter gets to do one
operation. The "granularity" of the clock is nowhere near the speed
of a microprocessor instruction set, and any comparison with assembly
languages doesn't make sense.

The difference between:

0 0 moveto

and

0 0 /arg2 exch def /arg1 exch def arg1 arg2 moveto

can sort of be measured in "ticks" of the interpreter's clock. It's
not quite this simple, since simply pushing a literal is faster than
executing a real PostScript operator, but it is a rough rule of thumb.
It will take about three times as long to execute the second of these
in a tight loop, and about five times as long if it is transmitted and
scanned each time. My rule of thumb is that if you have roughly the
same number of tokens in your stack approach as you do with your 'exch
def' approach, the 'exch def' is likely to be much more readable and
better. Otherwise, I usually go with the stack approach.

One other thing of note is that if you have too much stack manipulation
going on, it may well be symptomatic of a problem in the original program
design.

Also, most procedures don't do any stack manipulation at all, they
simply use their arguments directly from the stack. In this situation,
it is especially wasteful (and confusing, I think) to declare
intermediate variables.

Compare:

% sample procedure call:
(Text) 100 100 12 /Times-Roman SETTEXT

% approach 1:
/SETTEXT { %def
findfont exch scalefont setfont moveto show
} def

% approach 2:
/SETTEXT { %def
/arg5 exch def
/arg4 exch def
/arg3 exch def
/arg2 exch def
/arg1 exch def
arg5 findfont arg4 scalefont setfont
arg2 arg3 moveto arg1 show
} def

Which of these is easier for you to understand?

Anyway, I think the discussion is a good one, but let's not forget
that PostScript it is an interpreted language. And I don't think
it is terribly hard to use and understand, if it is written well.

Glenn Reid
Adobe Systems