[asdf-devel] Make the CL syntax predictable

Faré fahree at gmail.com
Fri Mar 14 20:29:42 UTC 2014


On Fri, Mar 14, 2014 at 4:01 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
>> Why this matters:
>> http://fare.tunes.org/files/tmp/asdf/asdf3-2014.html#%28part._.Safety_before_.Ubiquity%29
>
> You say "Creating a fresh copy of the standard readtable around each action is too expensive."
>
> But why expensive? On CCL it takes 22 microseconds per readtable:
>
OK, on my machine (Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz running at
1200 MHz),
it takes 4.3 µs on CCL and 3.2 µs on SBCL.

for l in sbcl ccl ; do
  cl -l $l "(uiop::implementation-identifier)" "(time (dotimes (i
1000000) (copy-readtable)))"
done

sbcl-1.1.14.43.master.1-9f3f7eb-linux-x64
Evaluation took:
  3.385 seconds of real time
  3.372000 seconds of total run time (3.360000 user, 0.012000 system)
  [ Run times consist of 0.196 seconds GC time, and 3.176 seconds non-GC time. ]
  99.62% CPU
  8,781,837,804 processor cycles
  5,903,919,248 bytes consed

NIL
ccl-1.10-f96-linux-x64
(DOTIMES (I 1000000) (COPY-READTABLE))
took 4,202,553 microseconds (4.202553 seconds) to run.
       394,066 microseconds (0.394066 seconds, 9.38%) of which was spent in GC.
During that period, and with 4 available CPU cores,
     4,164,000 microseconds (4.164000 seconds) were spent in user mode
        40,000 microseconds (0.040000 seconds) were spent in system mode
 1,696,000,000 bytes of memory allocated.
 924 minor page faults, 0 major page faults, 0 swaps.
NIL

Robert, what do you think? Should we "just" copy-readtable and
copy-pprint-dispatch around each action?
Or should we try to share the tables for all files in a system?
Should we try to have defsystem save the values of *readtable* and
*print-pprint-dispatch*,
while load-asd does the creation of fresh tables?
Should systems and/or individual components have a more general
purpose variables and variable-values slot,
which should be passed to progv, and be initialized from an alist?

Also, as for the implementation of such bindings, one issue I see with
the progv thing is that the more specific :around methods will be the
outer ones, so that our least specific default :around method will be
the innermost, and if it binds special variables, they will shadow
bindings from the user's :around method, e.g. in ironclad. I'm not
sure how to fix that in a backward-compatible way, short of
reintroducing the good/bad old asdf:around method combination — we
could of course split our a new method, just like we did with
perform-with-restarts. But that's quite ugly.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Microphones, liberating singers from having to be loud to be heard, gave back
to each language a music that matches its own prosody.



More information about the asdf-devel mailing list