The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

import-bot (20211) [Avatar] Offline
#1
[Originally posted by slbaumgartner]

A suggestion to augment your comparisons in chapter 1: what about the typical
amount of memory required for a task? In some cases this can be as critical a
factor as execution speed, and can be a motive for converting modules to C.

Here's my experience:
Strongly-typed, compiled languages use considerably less space for the same
data than loosely-typed, interpreted languages.

C [can be programmed to] use the least memory because it gives you complete
control.
C++ can match C if you avoid some of its OO features and memory-hungry
libraries, and usually comes close in any case.
Java seems to need a bit more than C++, and it is harder to dodge bloat from
OO because it is purer OO.
No experience with VB.

In a couple of quick tests, Python needed about 3-4x the memory to hold the
same data vs C.
Perl needed about 10% more than Python
JPython takes almost twice as much as Python (!)
I didn't test Tcl, but given its "multiported" object model (as of 8.0) would
expect it to take the most space.

The base executable sizes are also significant. On my NT box, an empty loop
in Python takes 2028K, in perl takes 1840K, and in jpython takes 7164K.
import-bot (20211) [Avatar] Offline
#2
Re: comparison of languages (memory usage)
[Originally posted by daryl harms]

Thanks Steve, this is a good suggestion. We left out memory usage comparison
under the assumption that with the current availability/price of memory, this
seems to rarely be an issue anymore (even for embedded designs -- at least for
new embedded designs).

But you are right, it would be a good idea to discuss it (especially since this
is an area where Python is weaker than C/C++).

Also, with some applications, even if you have no problem with handling the
size of the executable while running it on a target, you may also be concerned
with the amount of time it takes to download or move the executable over a low
speed link to the target machine in the first place.

The figures you give are very interesting. With Jpython you certainly may be in
the above mentioned situation of wanting to download the program.
The jpythonc Java byte-compiler has options that allow you to have
some control of the size of the footprint of the executable by limiting
the modules that are included.

There was one group who developed what they called "Deeply Embedded Python"
where they worked on paring down the base executable size to work
on hardware that only had 256K of memory. Their code (for version 1.5.1 of
Python) and information on what they did can be found at:
http://www.abo.fi/~iporres/python/

The point about the memory usage of dynamically-typed languages bears true.
It seems that a primary concern with them is that they inherently
execute slower than statically-typled languages. They will often contain
optimizations and implementation schemes that try to gain back some of that
loss of speed. And these will usually make the trade-off for speed at the
expense of extra memory usage.