From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d89e2d213646aec8 X-Google-Attributes: gid103376,public Path: controlnews3.google.com!news1.google.com!news.glorb.com!wns13feed!worldnet.att.net!attbi_s51.POSTED!53ab2750!not-for-mail From: "Jeff C," Newsgroups: comp.lang.ada References: Subject: Re: Mneson announcement and help request X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: NNTP-Posting-Host: 24.147.74.171 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s51 1086143188 24.147.74.171 (Wed, 02 Jun 2004 02:26:28 GMT) NNTP-Posting-Date: Wed, 02 Jun 2004 02:26:28 GMT Organization: Comcast Online Date: Wed, 02 Jun 2004 02:26:28 GMT Xref: controlnews3.google.com comp.lang.ada:1002 Date: 2004-06-02T02:26:28+00:00 List-Id: "Marius Amado Alves" 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.