I'm trying to decide whether it's worth spending $799 to get Lispworks
instead of just using CLisp. I know Lispworks has lots of advantages, but
one thing I'm wondering about is how long it takes to start. I would like
the program to start interacting with the user as quickly as possible after
he invokes it, such that he wouldn't usually notice the delay. I don't want
the user to say the program seems slow and blame it on Lisp. Even if the
program itself runs very fast, the startup delay is something the user would
notice every time he runs the program, because he has a reason to run it and
is therefore waiting for it to start interacting with him so he can tell it
what to do.
Does the $799 version of Lispworks start faster than the free version because
it doesn't spend time nagging about buying it? That seems obvious, but how
much of a factor is it? And are there any other factors that would make it
faster? And what about the tree-shaken delivered runtime programs? Would
they start significantly faster than Lispworks itself? That too seems
somewhat obvious, but again, how much of a factor is it?
And does anyone know how to get discounts on the $799? I know it's worth a
lot more than that, but I have to pay for it out of my own pocket, making
some sacrifices, which makes CLisp seem more attractive, except that I would
really rather use Lispworks and am willing to make some sacrifices for it,
but it's a close decision, even without considering the startup speed factor.
Hello,
re: startup time of LispWorks Professional:
This takes between 4 and 5 seconds on my system (to bring up the IDE).
If you use the application builder, which removes unused code, you might
even get faster startup times than the time it takes to bring up the IDE.
-Mark
--Mark Watson
--Java consulting, Open Source and Content: www.markwatson.com
········@badaddress.com writes:
> I'm trying to decide whether it's worth spending $799 to get Lispworks
> instead of just using CLisp. I know Lispworks has lots of advantages, but
> one thing I'm wondering about is how long it takes to start.
I was looking forward to a lively discussion of LW vs Clisp. I was very
surprised to see it narrowed in this way.
Do you mean the programmer development environment or a delivered application??
These are quite different.
> I would like
> the program to start interacting with the user as quickly as possible after
> he invokes it, such that he wouldn't usually notice the delay. I don't want
> the user to say the program seems slow and blame it on Lisp.
"the user"? Someone who programs in Lisp is going to give up and
program in C++ because he has to wait 3 seconds for a startup? (time, of
course, depends on your processor speed.)
> Even if the
> program itself runs very fast, the startup delay is something the user would
> notice every time he runs the program,
Once every day or two? On rare days, several times a day?
Come on, please be serious.
I can imagine start times that are impossibly slow, but I can't
believe you think LispWorks is in that range. LispWorks Enterprise
takes (counting aloud, not 100% accurate) 8 seconds to start on my 550
Mhz Win98 machine. Do I wish it took less? Yes, I wish all programs
stated instantly. But Symantec Visual Cafe takes 16 seconds. Microsoft
Word takes 13 seconds on the same machine. Adobe FrameMaker takes 6
seconds. Adobe PageMaker 15 seconds. MacroMedia Director 11 seconds.
Microsoft FrontPage is among the only serious programs I have that
starts in a time I can't complain about (3 seconds) [and probably
there's something that takes 30 seconds of the impossibly long system
boot-up time which enables this fast-start from the time I click the
application].
My conclusion? If this kind of timing matters to you, buy better hardware.
It is certainly cheaper for you to do that than for the industry to take
critical developers off of the development of much-needed software to do
a COMPLETELY cosmetic, make-work task like this.
Incidentally, a dumped world that has no special tuning but just does:
(defun goodbye-world ()
(capi:contain (make-instance 'capi:push-button
:callback #'(lambda (&rest args)
(system::bye)))))
(push '("Goodbye World" () goodbye-world) MP:*INITIAL-PROCESSES*)
(save-image "goodbye-world.exe"
:restart-function 'mp:initialize-multiprocessing
:environment nil
)
(quit)
takes about 2 seconds to start, even beating out front page.
> because he has a reason to run it and
> is therefore waiting for it to start interacting with him so he can tell it
> what to do.
I didn't understand this at all. Presumably all people who run programs
have a reason to run them and want to start interacting with them.
> Does the $799 version of Lispworks start faster than the free version because
> it doesn't spend time nagging about buying it? That seems obvious, but how
> much of a factor is it? And are there any other factors that would make it
> faster? And what about the tree-shaken delivered runtime programs? Would
> they start significantly faster than Lispworks itself? That too seems
> somewhat obvious, but again, how much of a factor is it?
I hope you're doing something with your programming that makes it worth
using Lisp for other reasons. Even if it starts fast, if this is your only
reason for choosing Lisp, I'd say it's not worth the effort.
> And does anyone know how to get discounts on the $799?
Someone posted here saying they were possible to obtain, but I think this
is an extremely fair price for the value you get, and comparable to the
commercial price of nearly every other piece of professional development
software you can buy.
Computer science is an expensive business. I'm living month to month
myself lately, but it didn't stop me from buying copies of all those
programs you saw me list above that start so slowly and yet cost $500
a pop. One needs good quality tools to do good quality work.
Invest in yourself. Do not treat this like the purchase of lawn furniture.
Either you have a realistic chance of making back many times over this amount
if you get any job at all, or else if you think you don't have such a chance,
you should get another line of work.
And as Tim points out, think of the economics. Suppose you could get
a lisp for free instead of paying $800. How many hours does it take
you to install and learn to use? How many hours to work around the
lack of various pretty tools that come with the professional versions?
How much are you billing you work out per hour? If you spend 10 or 20
hours getting set up with a free version, have you saved money or cost
money compared to getting a professional version that sets up more
quickly? Hitting the ground rolling with LispWorks is virtually
instantaneous. I often put off installation of programs (e.g., Adobe
products) because I expect it to be a burden, but LW is
extraordinarily low-pain and I've learned to look forward to its
comparatively simple/fast installations. You can be up and running in
minutes, and, if you're of a mind to, dumping deliverable applications
minutes later. Time is money.
> I know it's worth a
> lot more than that, but I have to pay for it out of my own pocket, making
> some sacrifices, which makes CLisp seem more attractive,
By all means, if CLisp is all you can afford, I don't mean to dissuade
you. One has to work within one's means.
But trying to make it sound like you'd have the money if only it would
start faster seems quite petty. You either have the money or you
don't.
And, btw, just a helpful tip for getting your way with vendors: if you
are identifying yourself as a cashless customer, that's not a way to
get the industry to divert its development base to tending to your
needs. Vendors, just like you, have to worry about their money. And
throwing large investments into customers who aren't willing to invest
back is usually not how most vendors make their decisions... This
statement is not the official party line of any vendor, of course;
they'll all tell you you're a great guy and that they want your
business. But I've been inside of enough vendors to know what the
trend is on this point...
> except that I would
> really rather use Lispworks and am willing to make some sacrifices for it,
> but it's a close decision, even without considering the startup speed factor.
There are other free/low-priced offerings to consider as well, btw.
Trust that you won't have to worry about startup speeds for delivered
applications under LispWorks. LispWorks doesn't mind bloat in the
IDE, it seems. But that has nothing to do with an application that's
delivered, where LispWorks does a great job with. Try to live with
the startup time for the IDE. Consider re-saving an image that
doesn't use any of the graphics libraries (e.g. CAPI), and work from
within Emacs. You have several alternatives.
It's not instantaneous that LispWorks pay for itself. I feel that if
you have a serious job, you'll need the LispWorks Enterprise license,
and that's $2k on Windows and Linux. But considering the time it
saves with respect to development, it really does pay for itself in no
time.
Xanalys has been very responsive to me with respect to bugs. Right
now, they are even adding database integration features for clients
like myself who need more portability and other features to facilitate
programming.
If the LispWorks license itself were free, but they charged the full
aforementioned prices just for the support, I'd still pay for it, and
I'm on a very limited budget too.
Still, if you're not doing contracts in Common Lisp, and money's an
issue, then CLISP is great, and does some cool stuff.
dave
········@badaddress.com wrote:
> I'm trying to decide whether it's worth spending $799 to get Lispworks
> instead of just using CLisp. I know Lispworks has lots of advantages, but
> one thing I'm wondering about is how long it takes to start.
My console-image of LispWorks 4.1 Enterprise needs somewhere around 2
Seconds to start.
If I use the "-init" option to give it this file:
;; hello.lisp
(format t "Hello World~%")
(quit)
and measure the time with the Unix "time" command:
Lispworks: ~ 0.9 sec
Lispworks (Treeshaken "Hello World"): First start, ~0.3 sec then 0.1 sec
CLISP: First start ~0.3 sec then ~0.2 sec
CMUCL: First start ~4sec. then ~0.15 sec
Note that the startup-time depends *much* on the image-size.
As you can see good at the timings CMUCL is by way the slowest on it's
first start. But then it beats the others. It seems that CMUCLs Image is
cached. CLISP has a really small image ~2MB AFAIK and therefore starts
faster. The delivered Lispworks "Hello World" is ~2MB big and has similar
timings as CLISP. So your startup-time seems to depend practically only on
the size of your image.
Regards,
Jochen
--
http://www.dataheaven.de
········@badaddress.com wrote:
> And what about the tree-shaken delivered runtime programs? Would
> they start significantly faster than Lispworks itself? That too seems
> somewhat obvious, but again, how much of a factor is it?
On my machine, a simple tree-shaken delivered Windows-based "Hello
World" program starts about 10 times as fast as the complete
development environment (for Lispworks Professional).
--
Arthur Lemmens
>>>>> "al" == Arthur Lemmens <········@xs4all.nl> writes:
al> ········@badaddress.com wrote:
>> And what about the tree-shaken delivered runtime programs? Would
>> they start significantly faster than Lispworks itself? That too
>> seems somewhat obvious, but again, how much of a factor is it?
arthur> On my machine, a simple tree-shaken delivered Windows-based
arthur> "Hello World" program starts about 10 times as fast as the
arthur> complete development environment (for Lispworks
arthur> Professional).
These tests are not exactly accurate, but the bottom line is that the
time it takes to start up a program is, in general, related to the
size of the program, as well as to what the program does once you
start it up. You should be able to deliver a reasonably-sized
LispWorks standalone program on Linux in only 5-6 Megs, done right.
I recently delivered a Corba-enabled server with quite a bit of
source, and the delivered image was just over 5 Megs. It includes
#'eval in the image as well. It starts up very fast, and runs very
fast too as compared to some of the free implementations on which I've
loaded the same code.
dave