iraf.net

A database interface has been part of the original IRAF design since 1984, but was never implemented. Originally, the idea was that the DBIO interface would be used to maintain all datafiles, keywords in image headers, data tables and so on. In the original design this was practically an implementation of an entire RDBMS system within IRAF, something not needed today where we have database systems that can be accessed via a daemon (e.g. mysql, postgres) or can be self-contained in text file (e.g. SQLite and accessed via an API.

[Note: I'd originally intended to be more prolific about these topics, sorry. Please comment on any suggestions you have for ideas, otherwise I may expand the topics to some non-IRAF projects that might be of interest]

IRAF is inherently a multi-process system (i.e. even a simple script requires binaries for the CL and perhaps several packages) and has always had the ability to run background jobs, but users sometime wonder whether tasks can be made multi-threaded as a means of improving performance for highly data-parallel operations (e.g. mosaic image processing). The short answer is that it is possible, but only with some restructuring of the core system, and of course needed changes to applications to enable the threading.

See below for more .....

A question that has often been asked over the years is whether IRAF would benefit from specialized hardware (e.g. the Altivec array processor on PPC systems) or high-performance compilers. The short answer is, it depends.

See below for further discussion .....

IRAF memory requirements are small by any measure; the system will happily process a Mosaic image on a machine with as little as 32MB of memory installed. This is due in large part to the fact that most tasks were written to process images in a line-by-line fashion rather than reading in an entire image, extensions of a mosaic MEF file are processed serially where possible. .....(read more below....)