langford@reed.UUCP (Chris Langford) (03/16/88)
Hi there,
I have been working on a little bit of PostScript code that prints
out digitized electrical signals. We collect neurobiological data, and
thus have to collect lots of data (14 k samples/sec for several 10s of
seconds at a time).
There are two problems I have:
1) The operand stack will only hold 500 objects, so I am (I think)
forced to have 100s of K of data broken down into groups of 500.
2) The virtual memory has only 174 K at most, and thus I must limit
the amount of data I can print per page to about 13K samples (about a
second worth of data).
I have been able to get our program to save data in nice bunchs of
450 (with brackets around it and everything), and do a restore before
I get a VM error, but it is still a real pain in the ass to print.
My questions are:
Is there any way to get the operand stack to accept a larger number of
objects, or bypass it altogether (I have not been able to get anything
else to work)?
Is there a way to get the LaserWriter to dump its font dictionarys,
and thus create more available memory?
Are there any other ways you can think of to get around this problem?
I know the serverdict password, so if it requires some monkey business,
I can handle it.
I have simplified the routine, but it
basically goes like this (if it helps):
[array of 450 integers here]
/data exch def
0 data 0 get moveto
0 2 data length 1 sub
{
data exch dup
/xval exch def
get
xval exch lineto
}
for
stroke
I have 2 channels of data alternating, so I do the same procedure
twice, but have the "for" loop begin with:
0 1 data length 1 sub
to get the other half of the data printed out.
Thanks for any help.
Chris Langford
tektronix!reed!langfordgreid@ondine (Glenn Reid) (03/17/88)
> 1) The operand stack will only hold 500 objects, so I am (I think) > forced to have 100s of K of data broken down into groups of 500. True. > 2) The virtual memory has only 174 K at most, and thus I must limit > the amount of data I can print per page to about 13K samples (about a > second worth of data). True, except that you don't really need to use any memory at all. > Is there any way to get the operand stack to accept a larger number of > objects, or bypass it altogether (I have not been able to get anything > else to work)? No. > Is there a way to get the LaserWriter to dump its font dictionarys, > and thus create more available memory? No. > Are there any other ways you can think of to get around this problem? Yes. What you are currently doing is putting 450 integers on the stack, allocating an array that can hold 450 numbers (about 3600 bytes), putting them all into that array, then pulling them out of the array two by two, putting them back on the operand stack, and calling "moveto" and "lineto". The solution is to use them directly from the stack in the first place and forget the array. You still have to "do something" every 450 data points or so, but you can go on forever without using any memory at all, and it isn't very hard: %!PS-Adobe-2.0 %%EndComments /chunkdraw { %def % assumption: the path can be drawn in either direction. % either the points have to be put out in the opposite % order, or you need to roll them on the stack. This % program assumes the easiest, but I can supply the % other if you need it. moveto % last two numbers on stack 448 { %repeat lineto } repeat stroke } bind def %%EndProlog 450 integers here % no array chunkdraw 450 integers here % no array chunkdraw 450 integers here % no array chunkdraw % ad infinitum... %%Trailer There are many variations on this theme, but the lesson is that there is no reason to take anything off the stack, do a "def", then put it right back onto the stack to use it. This can be applied to almost any PostScript programming problem with good success. A side effect is that it will probably run two or three times faster than it currently does. I hope this helps. Glenn Reid PostScript Software Support Adobe Systems Incorporate