615885a0fa
* New version of IRM New version of the IRM, updated to Medley. * moved to docs/medley-irm as discussed
57 lines
45 KiB
Plaintext
57 lines
45 KiB
Plaintext
INTERLISP-D REFERENCE MANUAL
|
||
PERFORMANCE ISSUES
|
||
|
||
"22"21. PERFORMANCE ISSUES
|
||
2
|
||
|
||
This chapter describes a number of areas that often contribute to performance problems in Medley programs. Many performance problems can be improved by optimizing the use of storage, since allocating and reclaiming large amounts of storage is expensive. Another tactic that can sometimes yield performance improvements is to change the use of variable bindings on the stack to reduce variable lookup time. There are a number of tools that can be used to determine which parts of a computation cause performance bottlenecks.
|
||
Storage Allocation and Garbage Collection
|
||
1
|
||
|
||
As an Medley application program runs, it creates data structures (allocated out of free storage space), manipulates them, and then discards them. If there were no way to reclaim this space, over time the Medley memory would fill up, and the computation would come to a halt. Actually, long before this could happen the system would probably become intolerably slow, due to ªdata fragmentation,º which occurs when the data currently in use are spread over many virtual memory pages, so that most of the computer time must be spent swapping disk pages into physical memory. The problem of fragmentation will occur in any situation where the virtual memory is significantly larger than the real physical memory. To reduce swapping, you want to keep the "working set" (the set of pages containing actively referenced data) as small as possible.
|
||
You can write programs that don't generate much ªgarbageº data, or which recycle data, but such programs tend to be complex and hard to debug. Spending effort writing such programs defeats the whole point of using a system with automatic storage allocation. An important part of any Lisp implementation is the ªgarbage collectorº that finds discarded data and reclaims its space.
|
||
There are several well-known approaches to garbage collection. One method is the traditional mark-and-sweep, which identifies ªgarbageº data by marking all accessible data structures, and then sweeping through the data spaces to find all unmarked objects (i.e., not referenced by any other object). This method is guaranteed to reclaim all garbage, but it takes time proportional to the number of allocated objects, which may be very large. Also, the time that a mark-and-sweep garbage collection takes is independent of the amount of garbage collected; it is possible to sweep through the whole virtual memory, and only recover a small amount of garbage.
|
||
For interactive applications, it is not acceptable to have long interruptions in a computation for to garbage collect. Medley solves this problem by using a reference-counting garbage collector. With this scheme, there is a table containing counts of how many times each object is referenced. This table is updated as pointers are created and discarded, incurring a small overhead distributed over the computation as a whole. (Note: References from the stack are not counted, but are handled separately at "sweep" time; thus the vast majority of data manipulations do not cause updates to this table.) At opportune moments, the garbage collector scans this table, and reclaims all objects that are no longer accessible (have a reference count of zero). The pause while objects are reclaimed is only the time for scanning the reference count tables (small) plus time proportional to the amount of garbage that has to be collected (typically less than a second). ªOpportuneº times occur when a certain number of cells have been allocated or when the system has been waiting for you to type something for long enough. The frequency of garbage collection is controlled by the functions and variables described below. For the best system performance, it is desirable to adjust these parameters for frequent, short garbage collections, which will not interrupt interactive applications for very long, and which will have the added benefit of reducing data fragmentation, keeping the working set small.
|
||
One problem with the Medley garbage collector is that not all garbage is guaranteed to be collected. Circular data structures, which point to themselves directly or indirectly, are never reclaimed, since their reference counts are always at least one. With time, this unreclaimable garbage may increase the working set to unacceptable levels. Some users have worked with the same Medley virtual memory for a very long time, but it is a good idea to occasionally save all of your functions in files, reinitialize Medley, and rebuild your system. Many users end their working day by issuing a command to rebuild their system and then leaving the machine to perform this task in their absence. If the system seems to be spending too much time swapping (an indication of fragmented working set), this procedure is definitely recommended.
|
||
Another limitation of the reference-counting garbage collector is that the table in which reference counts are maintained is of fixed size. For typical Lisp objects that are pointed to from exactly one place (e.g., the individual conses in a list), no burden is placed on this table, since objects whose reference count is 1 are not explicitly represented in the table. However, large, "rich" data structures, with many interconnections, backward links, cross references, etc, can contribute many entries to the reference count table. For example, if you created a data structure that functioned as a doubly-linked list, such a structure would contribute an entry (reference count 2) for each element.
|
||
When the reference count table fills up, the garbage collector can no longer maintain consistent reference counts, so it stops doing so altogether. At this point, a window appears on the screen with the following message, and the debugger is entered:
|
||
Internal garbage collector(GARBAGE% COLLECTOR NIL garbage% collector NIL (4) NIL) tables have overflowed, due
|
||
to too many pointers with reference count greater than 1.
|
||
*** The garbage collector is now disabled. ***
|
||
Save your work and reload as soon as possible.
|
||
[This message is slightly misleading, in that it should say "count not equal to 1". In the current implementation, the garbage collection of a large pointer array whose elements are not otherwise pointed to can place a special burden on the table, as each element's reference count simultaneously drops to zero and is thus added to the reference count table for the short period before the element is itself reclaimed.]
|
||
If you exit the debugger window (e.g., with the RETURN command), your computation can proceed; however, the garbage collector is no longer operating. Thus, your virtual memory will become cluttered with objects no longer accessible, and if you continue for long enough in the same virtual memory image you will eventually fill up the virtual memory backing store and grind to a halt.
|
||
|
||
Garbage collection in Medley is controlled by the following functions and variables:
|
||
(RECLAIM(RECLAIM (Function) NIL NIL ("22") 2)) [Function]
|
||
Initiates a garbage collection. Returns 0.
|
||
(RECLAIMMIN(RECLAIMMIN (Function) NIL NIL ("22") 2) N) [Function]
|
||
Sets the frequency of garbage collection. Interlisp keeps track of the number of cells of any type that have been allocated; when it reaches a given number, a garbage collection occurs. If N is non-NIL, this number is set to N. Returns the current setting of the number.
|
||
RECLAIMWAIT(RECLAIMWAIT (Variable) NIL NIL ("22") 2) [Variable]
|
||
Medley will invoke a RECLAIM if the system is idle and waiting for your input for RECLAIMWAIT seconds (currently set for 4 seconds).
|
||
(GCGAG(GCGAG (Function) NIL NIL ("22") 2) MESSAGE) [Function]
|
||
Sets the behavior that occurs while a garbage collection is taking place. If MESSAGE is non-NIL, the cursor is complemented during a RECLAIM; if MESSAGE = NIL, nothing happens. The value of GCGAG is its previous setting.
|
||
(GCTRP(GCGAG (Function) NIL NIL ("22") 2)) [Function]
|
||
Returns the number of cells until the next garbage collection, according to the RECLAIMMIN number.
|
||
The amount of storage allocated to different data types, how much of that storage is in use, and the amount of data fragmentation can be determined using the following function:
|
||
(STORAGE(STORAGE (Function) NIL NIL ("22") 2) TYPES PAGETHRESHOLD) [Function]
|
||
STORAGE prints out a summary, for each data type, of the amount of space allocated to the data type, and how much of that space is currently in use. If TYPES is non-NIL, STORAGE only lists statistics for the specified types. TYPES can be a symbol or a list of types. If PAGETHRESHOLD is non-NIL, then STORAGE only lists statistics for types that have at least PAGETHRESHOLD pages allocated to them.
|
||
STORAGE prints out a table with the column headings Type, Assigned, Free Items, In use, and Total alloc. Type is the name of the data type. Assigned is how much of your virtual memory is set aside for items of this type. Currently, memory is allocated in quanta of two pages (1024 bytes). The numbers under Assigned show the number of pages and the total number of items that fit on those pages. Free Items shows how many items are available to be allocated (using the create construct, Chapter 8); these constitute the "free list" for that data type. In use shows how many items of this type are currently in use, i.e., have pointers to them and hence have not been garbage collected. If this number is higher than your program seems to warrant, you may want to look for storage leaks. The sum of Free Items and In use is always the same as the total Assigned items. Total alloc is the total number of items of this type that have ever been allocated (see BOXCOUNT, in the Performance Measuring section below).
|
||
Note: The information about the number of items of type LISTP is only approximate, because list cells are allocated in a special way that precludes easy computation of the number of items per page.
|
||
Note: When a data type is redeclared, the data type name is reassigned. Pages which were assigned to instances of the old data type are labeled **DEALLOC**.
|
||
At the end of the table printout, STORAGE prints a "Data Spaces Summary" listing the number of pages allocated to the major data areas in the virtual address space: the space for fixed-length items (including datatypes), the space for variable-length items, and the space for symbols. Variable-length data types such as arrays have fixed-length "headers," which is why they also appear in the printout of fixed-length data types. Thus, the line printed for the BITMAP data type says how many bitmaps have been allocated, but the "assigned pages" column counts only the headers, not the space used by the variable-length part of the bitmap. This summary also lists "Remaining Pages" in relation to the largest possible virtual memory, not the size of the virtual memory backing file in use. This file may fill up, causing a STORAGE FULL error, long before the "Remaining Pages" numbers reach zero.
|
||
STORAGE also prints out information about the sizes of the entries on the variable-length data free list. The block sizes are broken down by the value of the variable STORAGE.ARRAYSIZES, initially (4 16 64 256 1024 4096 16384 NIL), which yields a printout of the form:
|
||
variable-datum free list:
|
||
le 4 26 items; 104 cells.
|
||
le 16 72 items; 783 cells.
|
||
le 64 36 items; 964 cells.
|
||
le 256 28 items; 3155 cells.
|
||
le 1024 3 items; 1175 cells.
|
||
le 4096 5 items; 8303 cells.
|
||
le 16384 3 items; 17067 cells.
|
||
others 1 items; 17559 cells.
|
||
This information can be useful in determining if the variable-length data space is fragmented. If most of the free space is composed of small items, then the allocator may not be able to find room for large items, and will extend the variable datum space. If this is extended too much, this could cause an ARRAYS FULL error, even if there is a lot of space left in little chunks.
|
||
(STORAGE.LEFT(STORAGE.LEFT (Function) NIL NIL ("22") 3)) [Function]
|
||
Provides a programmatic way of determining how much storage is left in the major data areas in the virtual address space. Returns a list of the form (MDSFREE MDSFRAC 8MBFRAC ATOMFREE ATOMFRAC), where the elements are interpreted as follows:
|
||
MDSFREE The number of free pages left in the main data space (which includes both fixed-length and variable-length data types).
|
||
MDSFRAC The fraction of the total possible main data space that is free.
|
||
8MBFRAC The fraction of the total main data space that is free, relative to eight megabytes.
|
||
This number is useful when using Medley on some early computers where the hardware limits the address space to eight megabytes. The function 32MBADDRESSABLE returns non-NIL if the currently running Medley system can use the full 32 megabyte address space.
|
||
ATOMFREE The number of free pages left in the symbol space.
|
||
ATOMFRAC The fraction of the total symbol space that is free.
|
||
Note: Another important space resource is the amount of the virtual memory backing file in use (see VMEMSIZE, Chapter 12). The system will crash if the virtual memory file is full, even if the address space is not exhausted.
|
||
Variable Bindings
|
||
1
|
||
|
||
Different implementations of Lisp use different methods of accessing free variables. The binding of variables occurs when a function or a PROG is entered. For example, if the function FOO has the definition (LAMBDA (A B) BODY), the variables A and B are bound so that any reference to A or B from BODY or any function called from BODY will refer to the arguments to the function FOO and not to the value of A or B from a higher level function. All variable names (symbols) have a top level value cell which is used if the variable has not been bound in any function. In discussions of variable access, it is useful to distinguish between three types of variable access: local, special and global. Local variable access is the use of a variable that is bound within the function from which it is used. Special variable access is the use of a variable that is bound by another function. Global variable access is the use of a variable that has not been bound in any function. We will often refer to a variable all of whose accesses are local as a "local variable." Similarly, a variable all of whose accesses are global we call a "global variable."
|
||
In a ªdeepº bound system, a variable is bound by saving on the stack the variable's name together with a value cell which contains that variable's new value. When a variable is accessed, its value is found by searching the stack for the most recent binding (occurrence) and retrieving the value stored there. If the variable is not found on the stack, the variable's top level value cell is used.
|
||
In a ªshallowº bound system, a variable is bound by saving on the stack the variable name and the variable's old value and putting the new value in the variable's top level value cell. When a variable is accessed, its value is always found in its top level value cell.
|
||
The deep binding scheme has one disadvantage: the amount of cpu time required to fetch the value of a variable depends on the stack distance between its use and its binding. The compiler can determine local variable accesses and compiles them as fetches directly from the stack. Thus this computation cost only arises in the use of variable not bound in the local frame ("free" variables). The process of finding the value of a free variable is called free variable lookup.
|
||
In a shallow bound system, the amount of cpu time required to fetch the value of a variable is constant regardless of whether the variable is local, special or global. The disadvantages of this scheme are that the actual binding of a variable takes longer (thus slowing down function call), the cells that contain the current in use values are spread throughout the space of all symbol value cells (thus increasing the working set size of functions) and context switching between processes requires unwinding and rewinding the stack (thus effectively prohibiting the use of context switching for many applications).
|
||
Medley uses deep binding, because of the working set considerations and the speed of context switching. The free variable lookup routine is microcoded, thus greatly reducing the search time. In benchmarks, the largest percentage of free variable lookup time was 20 percent of the total ellapsed time; the normal time was between 5 and 10 percent.
|
||
Because of the deep binding, you can sometimes significantly improve performance by declaring global variables. If a variable is declared global, the compiler will compile an access to that variable as a retrieval of its top level value, completely bypassing a stack search. This should be done only for variables that are never bound in functions, such as global databases and flags.
|
||
Global variable declarations should be done using the GLOBALVARS file manager command (Chapter 17). Its form is (GLOBALVARS VAR1 ... VARN).
|
||
Another way of improving performance is to declare variables as local within a function. Normally, all variables bound within a function have their names put on the stack, and these names are scanned during free variable lookup. If a variable is declared to be local within a function, its name is not put on the stack, so it is not scanned during free variable lookup, which may increase the speed of lookups. The compiler can also make some other optimizations if a variable is known to be local to a function.
|
||
A variable may be declared as local within a function by including the form (DECLARE (LOCALVARS VAR1 ... VARN)) following the argument list in the definition of the function. Local variable declarations only effect the compilation of a function. Interpreted functions put all of their variable names on the stack, regardless of any declarations.
|
||
Performance Measuring
|
||
1
|
||
|
||
This section describes functions that gather and display statistics abÿÿ o u t a c o m p u t a t i o n , s u c h a s a s t h e e l a p s e d t i m e , a n d t h e n u m b e r o f d a t a o b j e c t s o f d i f f e r e n t t y p e s a l l o c a t e d . T I M E A L L a n d T I M E g a t h e r s t a t i s t i c s o n t h e e v a l u a t i o n o f a s p e c i f i e d f o r m . B R E A K D O W N g a t h e r s s t a t i s t i c s o n i n d i v i d u a l f u n c t i o n s c a l l e d d u r i n g a c o m p u t a t i o n . T h e s e f u n c t i o n s c a n b e u s e d t o d e t e r m i n e w h i c h p a r t s o f a c o m p u t a t i o n a r e c o n s u m i n g t h e m o s t r e s o u r c e s ( t i m e , s t o r a g e , e t c . ) , a n d c o u l d m o s t p r o f i t a b l y b e i m p r o v e d .
|
||
( T I M E A L L(TIMEALL (Function) NIL NIL ("22") 6)ÿÿ T I M E F O R M N U M B E R O F T I M E S T I M E W H A T I N T E R P F L G ) [ N L a m b d a F u n c t i o n ]ÿ
|
||
Evaluates the form TIMEFORM and prints statistics on time spent in various categories (elapsed, keyboard wait, swapping time, gc) and data type allocation.
|
||
For more accurate measurement on small computations, NUMBEROFTIMES may be specified (its default is 1) to cause TIMEFORM to be executed NUMBEROFTIMES times. To improve the accuracy of timing open-coded operations in this case, TIMEALL compiles a form to execute TIMEFORM NUMBEROFTIMES times (unless INTERPFLG is non-NIL), and then times the execution of the compiled form.
|
||
Note: If TIMEALL is called with NUMBEROFTIMES > 1, the dummy form is compiled with compiler optimizations on. This means that it is not meaningful to use TIMEALL with very simple forms that are optimized out by the compiler. For example, (TIMEALL '(IPLUS 2 3) 1000) will time a compiled function which simply returns the number 5, since (IPLUS 2 3) is optimized to the integer 5.
|
||
TIMEWHAT restricts the statistics to specific categories. It can be an atom or list of datatypes to monitor, and/or the atom TIME to monitor time spent. Note that ordinarily, TIMEALL monitors all time and datatype usage, so this argument is rarely needed.
|
||
TIMEALL returns the value of the last evaluation of TIMEFORM.
|
||
(TIME(TIME (Function) NIL NIL ("22") 6) TIMEX TIMEN TIMETYP) [NLambda Function]
|
||
TIME evaluates the form TIMEX, and prints out the number of CONS cells allocated and computation time. Garbage collection time is subtracted out. This function has been largely replaced by TIMEALL.
|
||
If TIMEN is greater than 1, TIMEX is executed TIMEN times, and TIME prints out (number of conses)/TIMEN, and (computation time)/TIMEN. If TIMEN = NIL, it defaults to 1. This is useful for more accurate measurement on small computations.
|
||
If TIMETYP is 0, TIME measures and prints total real time as well as computation time. If TIMETYP = 3, TIME measures and prints garbage collection time as well as computation time. If TIMETYP = T, TIME measures and prints the number of pagefaults.
|
||
TIME returns the value of the last evaluation of TIMEX.
|
||
(BOXCOUNT(BOXCOUNT (Function) NIL NIL ("22") 6) TYPE N) [Function]
|
||
Returns the number of data objects of type TYPE allocated since this Interlisp system was created. TYPE can be any data type name (see TYPENAME, Chapter 8). If TYPE is NIL, it defaults to FIXP. If N is non-NIL, the corresponding counter is reset to N.
|
||
(CONSCOUNT(CONSCOUNT (Function) NIL NIL ("22") 6) N) [Function]
|
||
Returns the number of CONS cells allocated since this Interlisp system was created. If N is non-NIL, resets the counter to N. Equivalent to (BOXCOUNT 'LISTP N).
|
||
(PAGEFAULTS(PAGEFAULTS (Function) NIL NIL ("22") 6)) [Function]
|
||
Returns the number of page faults since this Interlisp system was created.
|
||
BREAKDOWN
|
||
1
|
||
|
||
TIMEALL collects statistics for whole computations. BREAKDOWN is available to analyze the breakdown of computation time (or any other measureable quantity) function by function.
|
||
(BREAKDOWN(BREAKDOWN (Function) NIL NIL ("22") 7) FN1 ... FNN) [NLambda NoSpread Function]
|
||
You call BREAKDOWN giving it a list of function names (unevaluated). These functions are modified so that they keep track of various statistics.
|
||
To remove functions from those being monitored, simply UNBREAK (Chapter 15) the functions, thereby restoring them to their original state. To add functions, call BREAKDOWN on the new functions. This will not reset the counters for any functions not on the new list. However (BREAKDOWN) will zero the counters of all functions being monitored.
|
||
The procedure used for measuring is such that if one function calls other and both are "broken down", then the time (or whatever quantity is being measured) spent in the inner function is not charged to the outer function as well.
|
||
BREAKDOWN will not give accurate results if a function being measured is not returned from normally, e.g., a lower RETFROM (or ERROR) bypasses it. In this case, all of the time (or whatever quantity is being measured) between the time that function is entered and the time the next function being measured is entered will be charged to the first function.
|
||
(BRKDWNRESULTS(BRKDWNRESULTS (Function) NIL NIL ("22") 7) RETURNVALUESFLG) [Function]
|
||
BRKDWNRESULTS prints the analysis of the statistics requested as well as the number of calls to each function. If RETURNVALUESFLG is non-NIL, BRKDWNRESULTS will not to print the results, but instead return them in the form of a list of elements of the form (FNNAME #CALLS VALUE).
|
||
Example:
|
||
¬ (BREAKDOWN SUPERPRINT SUBPRINT COMMENT1)
|
||
(SUPERPRINT SUBPRINT COMMENT1)
|
||
¬(PRETTYDEF '(SUPERPRINT) 'FOO)
|
||
FOO.;3
|
||
¬(BRKDWNRESULTS)
|
||
FUNCTIONS TIME #CALLS PER CALL %
|
||
SUPERPRINT 8.261 365 0.023 20
|
||
SUBPRINT 31.910 141 0.226 76
|
||
COMMENT1 1.612 8 0.201 4
|
||
TOTAL 41.783 514 0.081
|
||
NIL
|
||
¬(BRKDWNRESULTS T)
|
||
((SUPERPRINT 365 8261) (SUBPRINT 141 31910) (COMMENT1 8 1612))
|
||
BREAKDOWN can be used to measure other statistics, by setting the following variables:
|
||
BRKDWNTYPE(BRKDWNTYPE (Variable) NIL NIL ("22") 7) [Variable]
|
||
To use BREAKDOWN to measure other statistics, before calling BREAKDOWN, set the variable BRKDWNTYPE to the quantity of interest, e.g., TIME, CONSES, etc, or a list of such quantities. Whenever BREAKDOWN is called with BRKDWNTYPE not NIL, BREAKDOWN performs the necessary changes to its internal state to conform to the new analysis. In particular, if this is the first time an analysis is being run with a particular statistic, a measuring function will be defined, and the compiler will be called to compile it. The functions being broken down will be redefined to call this measuring function. When BREAKDOWN is through initializing, it sets BRKDWNTYPE back to NIL. Subsequent calls to BREAKDOWN will measure the new statistic until BRKDWNTYPE is again set and a new BREAKDOWN performed.
|
||
BRKDWNTYPES(BRKDWNTYPES (Variable) NIL NIL ("22") 8) [Variable]
|
||
The list BRKDWNTYPES contains the information used to analyze new statistics. Each entry on BRKDWNTYPES should be of the form (TYPE FORM FUNCTION), where TYPE is a statistic name (as would appear in BRKDWNTYPE), FORM computes the statistic, and FUNCTION (optional) converts the value of form to some more interesting quantity. For example, (TIME (CLOCK 2) (LAMBDA (X) (FQUOTIENT X 1000))) measures computation time and reports the result in seconds instead of milliseconds. BRKDWNTYPES currently contains entries for TIME, CONSES, PAGEFAULTS, BOXES, and FBOXES.
|
||
Example:
|
||
¬(SETQ BRKDWNTYPE '(TIME CONSES))
|
||
(TIME CONSES)
|
||
¬(BREAKDOWN MATCH CONSTRUCT)
|
||
(MATCH CONSTRUCT)
|
||
¬(FLIP '(A B C D E F G H C Z) '(.. $1 .. #2 ..) '(.. #3 ..))
|
||
(A B D E F G H Z)
|
||
¬(BRKDWNRESULTS)
|
||
FUNCTIONS TIME #CALLS PER CALL %
|
||
MATCH 0.036 1 0.036 54
|
||
CONSTRUCT 0.031 1 0.031 46
|
||
TOTAL 0.067 2 0.033
|
||
FUNCTIONS CONSES #CALLS PER CALL %
|
||
MATCH 32 1 32.000 40
|
||
CONSTRUCT 49 1 49.000 60
|
||
TOTAL 81 2 40.500
|
||
NIL
|
||
Occasionally, a function being analyzed is sufficiently fast that the overhead involved in measuring it obscures the actual time spent in the function. If you were using TIME, you would specify a value for TIMEN greater than 1 to give greater accuracy. A similar option is available for BREAKDOWN. You can specify that a function(s) be executed a multiple number of times for each measurement, and the average value reported, by including a number in the list of functions given to BREAKDOWN. For example, BREAKDOWN(EDITCOM EDIT4F 10 EDIT4E EQP) means normal breakdown for EDITCOM and EDIT4F but executes (the body of) EDIT4E and EQP 10 times each time they are called. Of course, the functions so measured must not cause any harmful side effects, since they are executed more than once for each call. The printout from BRKDWNRESULTS will look the same as though each function were run only once, except that the measurement will be more accurate.
|
||
Another way of obtaining more accurate measurement is to expand the call to the measuring function in-line. If the value of BRKDWNCOMPFLG is non-NIL (initially NIL), then whenever a function is broken-down, it will be redefined to call the measuring function, and then recompiled. The measuring function is expanded in-line via an appropriate macro. In addition, whenever BRKDWNTYPE is reset, the compiler is called for all functions for which BRKDWNCOMPFLG was set at the time they were originally broken-down, i.e. the setting of the flag at the time a function is broken-down determines whether the call to the measuring code is compiled in-line.
|
||
GAINSPACE
|
||
1
|
||
|
||
If you have large programs and databases, you may sometimes find yourself in a situation where you need to obtain more space, and are willing to pay the price of eliminating some or all of the context information that the various user-assistance facilities such as the programmer's assistant, file package, CLISP, etc., have accumulated during the course of his session. The function GAINSPACE provides an easy way to selectively throw away accumulated data:
|
||
(GAINSPACE(GAINSPACE (Function) NIL NIL ("22") 9)) [Function]
|
||
Prints a list of deletable objects, allowing you to specify at each point what should be discarded and what should be retained. For example:
|
||
¬(GAINSPACE)
|
||
purge history lists ? Yes
|
||
purge everything, or just the properties, e.g., SIDE, LISPXPRINT, etc. ?
|
||
just the properties
|
||
discard definitions on property lists ? Yes
|
||
discard old values of variables ? Yes
|
||
erase properties ? No
|
||
erase CLISP translations? Yes
|
||
GAINSPACE is driven by the list GAINSPACEFORMS. Each element on GAINSPACEFORMS is of the form (PRECHECK MESSAGE FORM KEYLST). If PRECHECK, when evaluated, returns NIL, GAINSPACE skips to the next entry. For example, you will not be asked whether or not to purge the history list if it is not enabled. Otherwise, ASKUSER (Chapter 26) is called with the indicated MESSAGE and the (optional) KEYLST. If you respond No, i.e., ASKUSER returns N, GAINSPACE skips to the next entry. Otherwise, FORM is evaluated with the variable RESPONSE bound to the value of ASKUSER. In the above example, the FORM for the "purge history lists" question calls ASKUSER to ask "purge everything, ..." only if you had responded Yes. If you had responded with Everything, the second question would not have been asked.
|
||
The "erase properties" question is driven by a list SMASHPROPSMENU. Each element on this list is of the form (MESSAGE . PROPS). You are prompted with MESSAGE (by ASKUSER), and if your response is Yes, PROPS is added to the list SMASHPROPS. The "discard definitions on property lists" and "discard old values of variables" questions also add to SMASHPROPS. You will not be prompted for any entry on SMASHPROPSMENU for which all of the corresponding properties are already on SMASHPROPS. SMASHPROPS is initially set to the value of SMASHPROPSLST. This permits you to specify in advance those properties which you always want discarded, and not be asked about them subsequently. After finishing all the entries on GAINSPACEFORMS, GAINSPACE checks to see if the value of SMASHPROPS is non-NIL, and if so, does a MAPATOMS, i.e., looks at every atom in the system, and erases the indicated properties.
|
||
You can change or add new entries to GAINSPACEFORMS or SMASHPROPSMENU, so that GAINSPACE can also be used to purge structures that your programs have accumulated.
|
||
Using Data Types Instead of Records
|
||
1
|
||
|
||
If a program uses large numbers of large data structures, there are several advantages to representing them as user data types rather than as list structures. The primary advantage is increased speed: accessing and setting the fields of a data type can be significantly faster than walking through a list with repeated CARs and CDRs. Also,
|
||
Compiled code for referencing data types is usually smaller. Finally, by reducing the number of objects created (one object against many list cells), this can reduce the expense of garbage collection.
|
||
User data types are declared by using the DATATYPE record type (Chapter 8). If a list structure has been defined using the RECORD record type (Chapter 8), and all accessing operations are written using the record package's fetch, replace, and create operations, changing from RECORDs to DATATYPEs only requires editing the record declaration (using EDITREC, Chapter 8) to replace declaration type RECORD by DATATYPE, and recompiling.
|
||
Note: There are some minor disadvantages: First, there is an upper limit on the number of data types that can exist. Also, space for data types is allocated two pages at a timeÿÿ . Eÿ ach data type which has any instances allocated has at least two pages assigned to it, which may be wasteful of space if there are only a few examples of a given data type. These problems should not effect most applications programs.
|
||
Using ªFastº and ªDestructiveº Functions
|
||
1
|
||
|
||
Among the functions used for manipulating objects of various data types, there are a number of functions which have "fast" and "destructive" versions. You should be aware of what these functions do, and when they should be used.
|
||
ªFastº functions: By convention, a function named by prefixing an existing function name with F indicates that the new function is a "fast" version of the old. These usually have the same definitions as the slower versions, but they compile open and run without any "safety" error checks. For example, FNTH runs faster than NTH, however, it does not make as many checks (for lists ending with anything but NIL, etc). If these functions are given arguments that are not in the form that they expect, their behavior is unpredictable; they may run forever, or cause a system error. In general, you should only use "fast" functions in code that has already been completely debugged, to speed it up.
|
||
ªDestructiveº functions: By convention, a function named by prefixing an existing function with D indicates the new function is a "destructive" version of the old one, which does not make any new structure but cannibalizes its argument(s). For example, REMOVE returns a copy of a list with a particular element removed, but DREMOVE actually changes the list structure of the list. (Unfortunately, not all destructive functions follow this naming convention: the destructive version of APPEND is NCONC.) You should be careful when using destructive functions that they do not inadvertantly change data structures.
|
||
(LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC "21-" "")) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD RIGHT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 9 FAMILY TIMESROMAN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC "21-" "")) (192 24 288 36) NIL) (TEXT NIL NIL (54 36 408 540) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC "21-" "")) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD LEFT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 9 FAMILY TIMESROMAN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC "21-" "")) (102 24 288 36) NIL) (HEADING NIL (HEADINGTYPE LEFTBACK) (96 612 516 36) NIL) (TEXT NIL NIL (102 36 456 540) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC "21-" "")) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD RIGHT) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 9 FAMILY TIMESROMAN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC "21-" "")) (192 24 288 36) NIL) (HEADING NIL (HEADINGTYPE RIGHTPAGE) (408 612 204 36) NIL) (TEXT NIL NIL (54 36 408 540) NIL))))) A È PAGEHEADING RIGHTPAGE T , ~ ~˜ , ~ ~˜ 2 6 T˜ T 5 º˜ ® º 2 ` ~˜ ~ , H H° @ È PAGEHEADING LEFTBACK T - È T , È 2 0 6°
|
||
° 3 0 6°
|
||
° T , ° 3 ° ( T , ° , ° , ° 3 ° ( T / ° PALATINO PALATINO PALATINO TITAN TITAN TITAN ÿý TITAN TITAN V H(DEFAULTFONT 1 (GACHA 10) (GACHA 8) (TERMINAL 8) (POSTSCRIPT (GACHA 8)))
|
||
MODERN
|
||
MODERN
|
||
|
||
IM.CHAP.GETFN MODERN
|
||
|
||
|
||
HRULE.GETFN MODERN
|
||
*
|
||
HRULE.GETFN MODERN
|
||
M ~ ” á G Á ü 7 IM.INDEX.GETFN µ ¥ <01> U % IM.INDEX.GETFN TITAN +
|
||
( IM.INDEX.GETFN MODERN
|
||
¿ - ) IM.INDEX.GETFN MODERN
|
||
6 ' # IM.INDEX.GETFN TITAN N & ! # IM.INDEX.GETFN TITAN P
|
||
± % IM.INDEX.GETFN TITAN
|
||
’ 1 )
|
||
4
|
||
- # ¡ R
|
||
? N ò
|
||
! N / 9 ‰ “ " ¦ f > ¡ ! ' # # # # # # # # 4 > * IM.INDEX.GETFN MODERN
|
||
– 1 y B V <00>
|
||
T 4 6 d v
|
||
HRULE.GETFN MODERN
|
||
|
||
‹ +
|
||
$ - æ <01>
|
||
Ý i ] ƒ 6
|
||
1 L
|
||
í
|
||
HRULE.GETFN MODERN
|
||
F ß
|
||
v Þ % IM.INDEX.GETFN TITAN & <00> 5
|
||
.
|
||
O
|
||
6
|
||
n N H v / L - " IM.INDEX.GETFN TITAN
|
||
|
||
Y ' N / - & IM.INDEX.GETFN MODERN
|
||
+ 5 ( ' IM.INDEX.GETFN TITAN >
|
||
( IM.INDEX.GETFN TITAN J
|
||
|
||
HRULE.GETFN MODERN
|
||
. u ' IM.INDEX.GETFN TITAN € 7 e i : ¼ * a à
|
||
+ IM.INDEX.GETFN TITAN
|
||
f
|
||
f + ) ) ) ) " ? M
|
||
( IM.INDEX.GETFN TITAN -
|
||
$ /
|
||
e "
|
||
&
|
||
) IM.INDEX.GETFN MODERN
|
||
I )
|
||
X 0 W
|
||
" = ( ( ( # ( ( ( # « M » ' ½
|
||
s }
|
||
Ó
|
||
&
|
||
Á
|
||
|
||
HRULE.GETFN MODERN
|
||
<01> B ' IM.INDEX.GETFN TITAN Ž
|
||
I , & ‰ + &
|
||
|
||
1 ,
|
||
%
|
||
- >
|
||
|
||
"
|
||
ª
|
||
P %
|
||
K $
|
||
HRULE.GETFN MODERN
|
||
@ Ê * J ^ 6 ) ² í )
|
||
HRULE.GETFN MODERN
|
||
æ _ Ñ O !
|
||
a <00> A › r
|
||
‚Úzº |