load(draw) is very slow (takes about 13 seconds)

My Apologies, I take it back.
I was using two maxima versions at the same time and the compiled files 
landed in the directory of the wrong maxima version.
package draw now has a decent load time:
"Evaluation took 0.4290 seconds (0.4280 elapsed) using 30.350 MB."

thanks a lot!
Max

Op 27-3-2013 9:42, Max Cohen schreef:
> Thank you so much for your very detailed help!
>
> Compiling went without problems.
> However, I do get stuck in the end: load (draw); still loads draw.lisp
> Also, file_search draw still shows th lisp file.
> I thought to circumvent this by loading the draw.fasl directly using 
> load("path_to_draw/draw.fasl")$
> but then the dependent files cannot be found.
>
> Do I need to change the file_search of file_type somehow?
>
> Met vriendelijke groet,
>
> Max Cohen
>
> Op 26-3-2013 18:05, Volker van Nek schreef:
>> Hi Max,
>>
>> attached you'll find step by step instructions to compile and load the
>> draw package with sbcl. The instructions are for Linux but should be
>> very similar in Windows. Don't know whether Windows complains about
>> write permissions in /share/draw.
>>
>> Good luck.
>>
>> Volker
>>
>> 2013/3/26 Max Cohen<m.cohen at sowiso.nl>:
>>> Hi Volkert,
>>>
>>> Thanks for your answer. I thought SBCL was the fastest LISP for maxima, but
>>> apparently this is not the case when it needs to compile.
>>> Explicitly compiling the package sounds like a good plan for me, but I would
>>> not know where to begin. Can you help me on my way?
>>>
>>> thanks in advance
>>> Max Cohen
>>> Op 25-3-2013 15:09, Volker van Nek schreef:
>>>
>>> 13 sec is a long time. But I do not expect that this is a bug. I don't
>>> know but I can imagine that sbcl compiles when loading. draw is an
>>> uncompiled share package written in Lisp. I expect draw benefits from
>>> being compiled. If you wish you can explicitely compile the lisp files
>>> in this package and load the binaries. If you do so please note that
>>> draw.lisp itself loads Lisp files. Lines 38/39:
>>> ($load "grcommon.lisp")
>>> ($load "vtk.lisp")
>>>
>>>
>>> For the record. This is what I get on a 32-Bit xubuntu (1.6 GHz
>>> DualCore). Note the amount of space that sbcl reclaims when loading
>>> draw.
>>>
>>> using Lisp SBCL 1.0.57.0.debian
>>> (%i2) load(draw);
>>> Evaluation took 3.8360 seconds (3.8430 elapsed) using 336.824 MB.
>>>
>>> using Lisp Clozure Common Lisp Version 1.8-r15286M  (LinuxX8632)
>>> (%i2) load(draw);
>>> Evaluation took 1.4760 seconds (1.4760 elapsed)
>>>
>>> using Lisp CMU Common Lisp Debian build debian/20c-2-1-g957a42a-dirty
>>> (20C Unicode)
>>> (%i2) load(draw);
>>> Evaluation took 0.1700 seconds (0.3400 elapsed) using 11.404 MB.
>>>
>>> using Lisp CLISP 2.49 (2010-07-07)
>>> (%i2) load(draw);
>>> Evaluation took 0.1640 seconds (0.1619 elapsed) using 5.021 MB.
>>>
>>> using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL)
>>> (%i2) load(draw);
>>> Evaluation took 0.0400 seconds (0.0400 elapsed)
>>>
>>>
>>> Volker van Nek
>>>
>>>
>>> 2013/3/25 Max Cohen<m.cohen at sowiso.nl>:
>>>
>>> Hello,
>>>
>>> On my system load(draw) is very slow (takes about 13 seconds).
>>> Loading other packages is fast.
>>>
>>> I?m on CentOS 5.9
>>> Maxima bug report tells me:
>>> Maxima version: "5.29.1"
>>> Maxima build date: "2013-03-25 10:57:26"
>>> Host type: "x86_64-unknown-linux-gnu"
>>> Lisp implementation type: "SBCL"
>>> Lisp implementation version: "1.0.38-2.el5"
>>>
>>> Anybody knows why this is so slow?
>>>
>>> regards
>>> Max Cohen
>>>
>>> _______________________________________________
>>> Maxima mailing list
>>> Maxima at math.utexas.edu
>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>>
>>>
>