"Darren New" <dne### [at] sanrrcom> wrote in message
news:49b41abe$1@news.povray.org...

> It would have been more gain had 64-bit computers not come along and
> eliminated the need to track that manually. Now, it's probably cheaper to
> install Win64 than it is to pay someone to code up a swap file in POV. :-)
> The power of mass market solutions trumps per-application solutions, in
this
> case.

Swapping to disk is immaterial of data bus width, it all depends on how much
physical memory you have installed. Physical memory is still relatively
expensive and not dense enough, there are physical and electronic
limitations, so even 64 bit systems shipping today may be limited to as
little as 6GB.

On top of that, for high efficiency, automatic memory management will not
beat application managed memory. It's the application that knows (or should
know, since moderns paradigms of today, carried out to the extreme, seem to
strive to make an application as ignorant as possible of the overall
picture) what data needs to be in memory and what data can be swapped out.
OS manages memory more or less blindly, ignorant of the application's
architecture or needs.

Not directly related, but one of my biggest beef is with applications that
don't know or care how big of data they are dealing with. Some archivers,
for instance, instead of uncompressing/compressing an archive to the
destination folder directly, uncompress it to a windows temporary folder,
and then copy it to the destination. It's assinine as it is, but for a 1MB
file, it's bearable. For a 1GB file, it's absolutely ridiculous. Similarly,
I've, on more than one occasion, cancelled a 2hr download by mistake and
went scrambling to the temporary internet files folder, because due to
thoughtless GUI design, the download window, with the *focus on cancel
button*, comes to the foreground once the download is complete and Windows
starts copying (again, assinine) the file from the temp folder to its
destination folder. That behaviour, as dumb as it is, may be acceptable for
a download that takes 2 seconds, and the shortsighted programmer surely did
not think of anything else, but not for a download that takes 2 hrs during
which time the user starts typing and working on other things on the
computer.

Similarly, a text/hex editor that uses the same method (of loading into
memory) for opening a 1KB file as a 1GB file is, to put it mildly, has got
to be written by monkeys. No application that deals with variable size data,
IMO, should be ignorant about the amount of data it may be dealing with, and
chose sensible strategies for different amounts of data.

Post a reply to this message