Juanjo <worm@arrakis.es> wrote:
+---------------
| I read your email and was playing only for one night with the
| CVS tree and got much better results:
|
| jlr@mpq3p46:~/src/ecls-new/build $ time ecl -eval '(quit)'
|
| real 0m0.154s
| user 0m0.150s
| sys 0m0.003s
| jlr@mpq3p46:~/src/ecls-new/build $ time lisp -eval '(quit)'
|
| real 0m0.017s
| user 0m0.010s
| sys 0m0.007s
|
| The first one is ECL as of my local CVS tree (to be committed by the
| end of the week), the second one is CMUCL.
+---------------
*Much* better indeed! Still not as snappy as either CMUCL or CLISP,
obviously, but already enough better than it's usable for some kinds
of scripting [though maybe still not for heavily-used CGI scripts].
I'm looking forward to the improved one being available, thanks!!
+---------------
| The message now is the following. Why did ECL have "long" start times?
| Because nobody cared much about the opposite. 770 ms was ok for me.
| Nobody complained in the mailing list and hence the reduced group of
| developers did nothing about it.
|
| But there is plenty of room for improvement, as I have already shown.
| So if instead of writing this message to comp.lang.lisp you had sent
| either a bug report to the mailing list, maybe we would have done
| something to that respect before. Incidentally, I do not read
| comp.lang.lisp that often.
+---------------
I understand. You have not been specifically targeting the "scripting"
area before, and therefore have not optimized for it. On the other hand,
please consider the circumstances under which I tried ECL for the very
first time:
- I saw your comp.lang.lisp posting of May 21st, announcing the
release of ECL 0.9f.
- A few weeks later, having a spare moment, I grabbed the source
and compiled it for an x86_64 platform, mostly uneventfully
[except for some permissions problems with the "make install" --
by default Linux doesn't let root write on non-root-writable
files -- which was hacked through with only minor effort], and
tried out the generation of native executables. It worked just
fine, though I did notice the slow startup time.
- Then I saw your comp.lang.lisp posting of July 12th in this thread,
again pointing out that ECL can "produce native standalone executables,
shared libraries and loadable modules", so I replied to this, noting
that there was a issue with using it for general "scripting" due to
the startup time.
Note that so far *everything* I know about ECL I've gotten from
comp.lang.lisp, a newsgroup, a medium which I *much* prefer to
mailing lists!!
I imagine that many others are probably in the same situation,
not just with ECL, but with many implementations: one hears about
something on c.l.lisp, goes off & tries it, perhaps comments on
the experience back to the group, and leaves it at that, especially
if one already has existing alternatives that work "well enough".
It's unlikely that a casual user will join an implementation-specific
mailing list in that case, *especially* if one is browsing through a
large number of implementations.
Note that this tension between a general newsgroup (comp.lang.lisp
in this case) and implementation-specific mailing lists applies to
many other Common Lisp implementations besides ECL, and even to many
other things besides Common Lisp! ;-} ;-} I understand that detailed
discussions of specific implementation details among active developers
and serious users might be better done in a mailing list, but at
the same time there should be some openness to input on a general
newsgroup from "casual" users, who often stumble across things in
the weirdest corners!
Again, thanks for the factor-of-5 speedup in starting time of ECL
native executables! It's certainly brought it into the range of
reasonable times for "scripting" applications, especially if the
speedup also applies to "#!/usr/local/bin/ecl -shell" scripts
[which it should]. I look forward to seeing the new version soon...
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607