Pebblestone wrote:
> Do I need to proclaim optimize preference before install asdf packages?
I've done some test. And the answer is yes, proclaim influences how the
asdf package is compiled.
Here're something simple I've done.
========================================================
Platform: FreeBSD 6.1 + SBCL 0.9.9
Test case: (times 50000 (split-sequence:split-sequence #\space "I love
you."))
Which utilizes time macro to repeat 50000 times and give the report of
how many time has passed.
1) proclaim optimize as excessively optimized for speed: (speed 3)
(safety 0) (debug 0) (space 0)
Evaluation took:
0.327 seconds of real time
0.325701 seconds of user run time
0.0 seconds of system run time
0 page faults and
7,994,464 bytes consed.
2) proclaim optimize as default: (speed 1) (safety 1) (space 1) (debug
2)
Evaluation took:
0.437 seconds of real time
0.435053 seconds of user run time
0.0 seconds of system run time
0 page faults and
9,195,088 bytes consed.
3) proclaim optimize as debug biased: (speed 1) (safety 1) (space 1)
(debug 3)
Evaluation took:
0.836 seconds of real time
0.832011 seconds of user run time
1.72e-4 seconds of system run time
0 page faults and
26,403,096 bytes consed.
4) proclaim optimized as speed biased: (speed 2) (safety 1) (space 1)
(debug 1)
Evaluation took:
0.357 seconds of real time
0.356399 seconds of user run time
0.0 seconds of system run time
0 page faults and
8,001,744 bytes consed.
==========================================================
Although the first case is the fastest, but SBCL will remove document
and arglist information of the function so it's not good for
programming.
I found that the last case might be more suitable for development.
Because:
1) It preserves document and arglist information of functions, which is
essential for program writing.
2) Released packages are supposed to have less bugs, so there's less
chance for us to debug into packages.
Also, the default optimize preference is acceptable with only 20%
performance loss.
What's your opinion?
Pebblestone wrote:
> 4) proclaim optimized as speed biased: (speed 2) (safety 1) (space 1)
> (debug 1)
> Evaluation took:
> 0.357 seconds of real time
> 0.356399 seconds of user run time
> 0.0 seconds of system run time
> 0 page faults and
> 8,001,744 bytes consed.
>
> ==========================================================
>
> Although the first case is the fastest, but SBCL will remove document
> and arglist information of the function so it's not good for
> programming.
>
> I found that the last case might be more suitable for development.
> Because:
> 1) It preserves document and arglist information of functions, which is
> essential for program writing.
> 2) Released packages are supposed to have less bugs, so there's less
> chance for us to debug into packages.
>
> Also, the default optimize preference is acceptable with only 20%
> performance loss.
>
> What's your opinion?
AFAIK to I prefer (speed 3) (safety 1) (space 1) (debug 1) [and maybe
(compilation-speed 0)] for libraries.
I may be wrong, but only the debug declaration affects whether useful
info is saved (I got bitten by this when trying to overoptimize
and noticing that there is no arglist info. :-)
Thus I prefer to leave the debug declaration alone, as it doesn't affect
speed that much.