fastgets.doc 4.0 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
  1. FAST PROPERTY ACCESS IN CSL/CCL
  2. ===============================
  3. The "fast-get" facility in CSL arranges that for a number of user-specified
  4. property names (used with both GET and FLAGP) the access has constant cost.
  5. Normally access to a property involves searching a property list, and if one
  6. symbol has many properties this can be tedious - with a worst case in the
  7. fairly common circumstance that the property is not found.
  8. To speed up CSL I allocate 6 bits in a symbol header that influence how that
  9. symbol is treated when used as a property name. One code is reserved to
  10. mean "use a normal property list", leaving 63 codes for fast access. The
  11. first of these is reserved for a property called 'NONCOM because the built-in
  12. ORDERP function wants to use this for compatibility with REDUCE.
  13. A tag must be marked as "fast" before any properties with that indicated are
  14. set up. If this constraint is not adhered to then properties can end up
  15. stored in inconsistent or redundant forms. The protocol is to select an
  16. integer in the range 0 to 63 for each tag to be handled specially, and then
  17. to make a call such as
  18. (symbol-make-fastget 'noncom 0)
  19. (symbol-make-fastget 'my_property_name 1)
  20. (flag '(a b c) 'noncom)
  21. (put 'x 'my_property_name 'y)
  22. or (setf (get 'x 'my_property_name) 'y)
  23. The fast-get status of a symbol can be inspected using
  24. (symbol-fast-get 'x nil)
  25. or reset to have no special treatment (please do not do this!)
  26. (symbol-fast-get 'x -1)
  27. When a symbol is given a "fast" property a vector of length 63 is created
  28. and a word in the symbol's header is made to point to it. The vector contains
  29. either property values ir a marker that indicates that no property is
  30. present. A call (symbol-fastgets 'x) can retrieve the vector and can be
  31. useful while debugging, maybe.
  32. If you inspect the property list of an object (using the PLIST function) then
  33. any fast properties are extracted from the vector and built onto the front
  34. of the property list as returned. Of course this means that altering the
  35. property list using RPLACx may not be useful!
  36. The function GET retrieves a property. In Common Lisp mode the three-argument
  37. version (GET a b c) allows c to be returned as a default value if the
  38. property sought is not present. The two-argument version can not distinguish
  39. between a property whose value is NIL and not having a property present
  40. at all. The function FLAGP returns T if a property is present (whatever
  41. value is associated, including the case where the stored value is NIL). The
  42. function FLAG just sets properties, giving them the value T in a somewhat
  43. arbitrary way.
  44. Clearly use of fast gets consumes memory, but because many of the extra
  45. vectors contain many NIL elements they compress well in image files, which
  46. therefore do not grow too badly. To decide which properties are most
  47. critical you can run tests using the profiled version of the bytecode
  48. interpreter (bytes.c rather than bytes1.c), and after a run call the
  49. function (BYTECOUNTS). You need to adjust your build sequence so that
  50. the file bytes.c is compiled with RECORD_GET defined, e.g. by putting
  51. -DRECORD_GET
  52. among the flags passed to your C compiler. Note that this option will slow
  53. things down noticeably. The output from BYTECOUNTS indicates which property
  54. tags were used, and how many unsuccessful searches for each tag occurred. This
  55. latter information is collected because unsuccessful searches are the worst
  56. case for a traditional property list search.
  57. Note that when a property is handled "fast" it is not stored on the regular
  58. property list (the only information about it is in the vector). Thus if the
  59. most commonly used properties have been handled this way the average length
  60. of property lists will shrink and so access to all other properties is
  61. slightly speeded up too.
  62. By editing FASTGET_SIZE in the source file "tags.h" if would be possible to
  63. make the symbol extension vectors smaller than 63 items long, so in
  64. cases where a much smaller set of tags is important the system can
  65. be configured to save some memory.