[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