help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs & Lisp question


From: Tim X
Subject: Re: Emacs & Lisp question
Date: Sat, 27 Jun 2009 15:52:55 +1000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Ben Badgley <mortecanine@peoplepc.com> writes:

> Been using Google all day to no avail. I think it is pretty straight
> forward question.
>
> Can you use compressed Lisp code? Will it evaluate, compile and evaluate?
>
> The reason I ask is due to looking at the Emacs directory. The Lisp code
> directory sure does eat up a lot of space. So, it came to mind, "why not
> compress each of those buggers and let the interpreter use them from the
> archives?"
>
> Will Emacs allow this? Further is it even doable beyond Emacs?
>
> This may not be exactly the best place for me to ask, understood. I am
> trying to keep it related to Emacs on a general usage level. If we can use
> compressed libraries, wouldn't it be worth knowing? ;-)
>
>
> ---

When you do a make install of emacs 22 or 23, the *.el files are all
gzipped. As far as I know, emacs can handle gzipped *.el files, but the
*.elc files cannot be compressed. 

Compression can be a two edged sword. On one hand, you reduce storage
space. However, on the other, the files genraly must be uncompressed
before the application can interpret the code. This can cause overhead
that may slow down an applications execution. Of course, a lot of
variables come into play - to some extent, its similar to using
compression on an ssh connection. If the data your transferring around
is really large, compression is usually beneficial. However, if the data
you are transferring around is small, the overhead of compression and
uncompression may be higher than the benefits obtained by transferring
the file. Likewise, with emacs (or any other application that loads
libraries), if the library files are small, the overheads of compression
may slow down loading. If the libraries are large, the overheads of
compression may be offset by smaller storage/memory requirements etc. 

The other issue to consider and for which I have no data is to what
extent the data is able to be compressed. some data compresses really
well, while other data gives pretty poor results. A lot also depends on
the type of compression being used. 

And finally, you also have to consider the profiel of the system your
running on. If you have a system with very fast CPU and restricted
storage, compression may be beneficial. However, if you have slower CPUs
or large amounts of available storage with good disk IO etc, compression
may not actually be of any real benefit - maybe even a negative benefit.

Tim




-- 
tcross (at) rapttech dot com dot au


reply via email to

[Prev in Thread] Current Thread [Next in Thread]