luser-dr00g
commented
2 years ago Another one with more obvious use is selecting the default device. Maybe somebody will want a version where the default device is pgmimage? or the null device, then you could run PS programs more like shell scripts without opening a graphics window by default.
Currently a configuration like this could arise if there are no windowing libraries available. But it might be nice if this were a configuration choice one could make even if windows are available.
vtorri
While we're looking at the project afresh with big picture concerns, it occurs to me that there's a lot of configuration possibilities kinda buried in header files and maybe in the code itself that could or should be teased out and analyzed in a somewhat systematic way.
For starters, various data structures have tweakable sizes like the number of elements in a stack segment and the size of a segmented memory table (XX ... no wait scratch that one, we got rid of that). Also the conditions that trigger a garbage collection are configurable.
So for starters, there are these additional "configuration parameters" in addition to the ones accessible with
./configure:xpost_memory.h:
define XPOST_MEMORY_TABLE_SIZE 2000 // not this one, but this needs a //TODO remove?
xpost_stack.h:
define XPOST_STACK_SEGMENT_SIZE 1000
xpost_free.h: XPOST_GARBAGE_COLLECTION_PERIOD = 20000, /*< number of times to grow before collecting / XPOST_GARBAGE_COLLECTION_THRESHOLD = 1000000000 /*< number of bytes to allocate before collecting /
define XPOST_FREE_ACCEPT_OVERSIZE 3
define XPOST_FREE_ACCEPT_DENOM 2
And that's not even to mention WANT_LARGE_OBJECT.
So is there a tool, or a least a methodology for experimenting with these numbers to find better performance? I imagine we'll need a suite of example PostScript programs to run while instrumenting the program somehow. Is there a tool from the valgrind team for speed or just use unix
timeortimex?