[Pdx-pm] RE: [Pdx-pm] Software development and The Rules

Austin Schutz tex at off.org
Thu Sep 26 15:12:30 CDT 2002

On Wed, Sep 25, 2002 at 04:10:38PM -0700, Joshua Keroes wrote:
> On (Wed, Sep 25 16:03), Curtis Poe wrote:
> > ----- Original Message -----
> > From: "Joshua Keroes" <jkeroes at eli.net>
> > 
> > > Nope, that's not it. For one thing, you've just read 1_000_000
> > > numbers into memory, that's 7 bytes * 1_000_000 of space of the
> > > disk.
> > >
> > > -Joshua
> > 
> > Whoops!  We're talking Perl here :)  I don't have hard numbers, but I
> > estimate that a simple scalar in Perl has at least 12 bytes: 4 for the
> > pointer, 4 for the reference count, 3 for the flags and 1 (?) for the type;
> > see perlguts for more info.  Abigail has stated that there is actually 24
> > bytes of overhead per scalar
> > (http://www.perlmonks.org/index.pl?node_id=190458 -- any Perl internals
> > gurus care to illuminate me on what I missed?).
> > 
> > As a result, if Abigail's figure is correct, that's 24_000_000 bytes plus
> > 7_000_000 bytes, for a total of 31_000_000 bytes of memory for one million
> > phone numbers.
> Given Unicode these days, it may even be twice that. So the point stands,
> there is a solution to this problem that is much better than allocating
> 20-30 MB of RAM.

	My three year old computer has 256 megs of ram with a gig of swap.

	If you asked something like 'how do I sort every phone number in the
entire U.S.?', perhaps that's a different question. Maybe then I would
care about memory usage or processing time a little more. Depends on the
application. Most of the time I will have the numbers sorted letting the
computer do most of the thinking for me before a smarter person will have
programmed a more clever way of doing it.

	By and large a computer can do practically anything I have need of
doing without having to resort to smarts. That's the beauty of a sloppy
but effective language like perl on a modern computer. By sloppy I refer to
the relatively freeform syntax of the language, as compared with very
structured languages such as java, etc.

	I'm not suggesting programming for performance is without merit. There
are times when you have such a tremendous dataset or a need to do very fast
data processing where it's critical to have the computer use optimal
algorithms. It has been my experience that this is the exception, and not the
rule. If you're writing a device driver, for example, you generally want
the code to be compact and as efficient as possible - and most likely not
Perl. ;-)

	One of the reasons Inline::C is so cool is that you can take a program
which is too slow/inefficient, and give it a big boost in places that are
particularly slow.  If you had to run the phone number sorter 20 times a minute
that might be a better option than the quick and dirty pure perl version.
	Do you need to sort all the numbers in the portland area 20 times a


More information about the Pdx-pm-list mailing list