Re: Mneson announcement and help request

["Jeff C," <jcreem@yahoo.com>]

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.28.1086105372.391.comp.lang.ada@ada-france.org...
> Mneson is a developing 100% Ada database system. Latest version 20040601.
>
>    http://www.liacc.up.pt/~maa/mneson
>
> The core seems well, but there's a problem in an auxiliary module that I'm
> having difficulty analysing due to an aparent gprof bug. So I appreciate
the
> help of anyone interested in making Ada the next generation database
> technology :-)
>


I know conventional wisdom is that one should not Optimize without
profiling....But since don't even
understand your program structure I would need to take more time to
understand its flow before
understanding the profile data.

So...At the risk of making suggestions that may not apply to speed I'll make
one that applies to style.

In general, I hate to see code that uses exceptions for normal control flow
processing. It certainly appears to
me that your code that makes use of the various For_Each_XXX type procedures
uses an exception
raise to terminate the search when "done".

This is not really desireable from a style point of view and also can
generally be a performance hit.
On compilers that implement zero-cost-exceptions of some sort, the "cost" is
high (or higher) on each
exception occurance.

On compilers that do not implement it, the presence of an exception handler
causes some overhead.

While this is generally small, having this in a traversal search really can
add up over time. In your case, in places like Get_Element and Get_Instance
a "normal" call involves a double exception throw.

In these cases it looks like you wrote your own traverse type procedures and
you want to terminate
the traverse "early" . .. For any container I ever created a Traverse for I
typically provide a pattern like

generic
    with Procedure Process_Element(The_Element : in out Element_Type;
                                                        Terminate_Traverse :
in out Boolean);
procedure Traverse(Container : in Container_Type);


Where the generic body of Traverse checks the Terminate_Traverse out
parameter of Process_Element each
time to see if it should prematurely stop traverse.

Clients need to write Process_Element so it explicitly sets
Terminate_Traverse to true if they want to
stop.  Traverse sets it false before "looping" and checks it after each call
to Process_Element.

In any case, it is not a perfect solution but it avoids the kludges of
multiple exceptions for non-error
based processing.

Again, this may or may not help your performance issue....but it would help
the overall program style IMHO.

Others may not agree with me. Perhaps there is a feeling that using
exceptions for this type of processing
is acceptable and that I am being too ivory tower.......your call.