[Melbourne-pm] Error checks without packages

Toby Corkindale toby.corkindale at strategicdata.com.au
Mon Aug 1 18:26:46 PDT 2011

On 02/08/11 11:13, Tim Hogard wrote:
>> Hi Tim,
>> What are you looking to optimise here? It sounds like you're
>> concentrating on start-up/initialisation performance?
> Its a combo of things.  This thing needs to be audited so each line
> is extra money.  There is the performace issues as well when it
> gets hit hard.  The performace issue is also related to energy
> use since most of the time the overweight servers it runs on
> are doing nothing.  It also deals with real money so
> I must avoid unintended consequences.  And there is quite a
> bit of "old school programmer" asking "why is it doing that?"

The reason I ask is that if you're writing a high-performance app, then 
the best way to avoid the performance hit of initialisation, is to avoid 
it completely. I know this increases the program's complexity slightly, 
but it is one of the easiest ways to improve performance.

ioe. Create a program that starts up and remains running, awaiting 
further input, and processing it immediately as it appears.

This is now common accepted practice for web apps (compare fastcgi, 
plack, etc vs how we did things with cgi scripts last century).
However I'm sure you're aware you can write longer-lasting scripts for 
other situations. For instance if you're waiting for file input, you can 
use select() to wait for it in a specific filehandle, or inotify [1] to 
wait for files to appear in certain directories.

As far as auditing goes - are there certain common libraries which have 
already been certified for use on your systems? If so, perhaps using 
them could reduce your auditing scale, rather than having to duplicate 
their functionality yourself?
Just a thought; not sure if it applies to your case.


[1: via something like 
http://search.cpan.org/~mlehmann/Linux-Inotify2-1.22/, or whatever the 
Solaris equivalent is.]

More information about the Melbourne-pm mailing list