What should I watch for if I write small programs in Common Lisp, which don't do much. I wrote a program that only executes some small functions to interact with the desktop-manager.
But the execution of the program has a recognizable duration (should be faster)
Would it be faster if not the whole common lisp system were included? How can I only load functions, I will need in the program?
Does it affect the execution speed if I don't compile the file, but only create the executable after loading, when I use sbcl? (normally it should always compile I think, there can be many problems, when I use compile-file, because not everything is done normally)
How useful are type-declarations? I think, they do not use much if there are multiple possibilities (for example the type "(or number symbol string char)")
Should I let the Program opened and not reload it every time I use a command (because I need it very often, but there is no initialization that only would run one time)? (I don't know how I should do this, if it is useful)
That's it! I hope, someone can help.
PS:
I use trivial-shell:shell-command to execute commands and cl-json to read some input, I don't know, if they may be slow
Optimizing Common Lisp Speed and executable Size
Re: Optimizing Common Lisp Speed and executable Size
Most likely, the bottleneck is the loading of external libraries, i. e. trivial-shell and cl-json. You could time your function in the REPL using the TIME function and time your script in the shell, I guess the former must take much less time than the latter.
Personally, for small script-like programs I use a custom SBCL core with all the libraries I need (and I add new libraries as I need them). This approach "factors out" SBCL, while the startup time becomes quite acceptable. Usually I write a Lisp file and use cl-launch to produce a small executable script wrapper.
The usefulness of type declarations varies, but I don't think they are crucial in your case, anyway.
Theoretically, you can have a running Lisp server, but probably it's more trouble than it's worth.
I'd suggest you to find out if loading libraries is indeed the bottleneck and to try to use a core containing them. Write about your progress.
Personally, for small script-like programs I use a custom SBCL core with all the libraries I need (and I add new libraries as I need them). This approach "factors out" SBCL, while the startup time becomes quite acceptable. Usually I write a Lisp file and use cl-launch to produce a small executable script wrapper.
The usefulness of type declarations varies, but I don't think they are crucial in your case, anyway.
Theoretically, you can have a running Lisp server, but probably it's more trouble than it's worth.
I'd suggest you to find out if loading libraries is indeed the bottleneck and to try to use a core containing them. Write about your progress.

Re: Optimizing Common Lisp Speed and executable Size
Unfortunately, this is not possible, at least not with free implementations.porky11 wrote: How can I only load functions, I will need in the program?
Re: Optimizing Common Lisp Speed and executable Size
Thanks, I should read more about custom kernels. But for this problem they will not help.
I compared the time of running the main-function in sbcl and the time of running the executable in terminal and they are the same (0.130s only for switching workspaces) So the core is not the problem.
If you want to, I could upload the file somewhere (where?), but I use some self-written utilities and if you want to test it, you should be using i3 as window manager.
I compared the time of running the main-function in sbcl and the time of running the executable in terminal and they are the same (0.130s only for switching workspaces) So the core is not the problem.
If you want to, I could upload the file somewhere (where?), but I use some self-written utilities and if you want to test it, you should be using i3 as window manager.
Re: Optimizing Common Lisp Speed and executable Size
Well, I doubt anyone's going to know why a function is slow without having some idea of what it does, or whether any variations on its implementation have been tried.