Re: [Ada-mode-users] Performance of ada_mode_wisi_lr1_parse.exe vs. abort statements

[Ludovic Brenta]

Le 2018-12-18 00:46, Stephen Leake writes:
> Ludovic Brenta <address@hidden> writes:
>
> > Philippe has made some measurements of the performance
> > of ada_mode_wisi_lr1_parse.exe under callgrind and found
> > that approximately 10% of CPU time is spent in instructions
> > perparing for a possible abort statement.
>
> Just to be clear, what version of GNAT are you compiling with? I'm 
> using
> CE 2018 on Windows, and Pro 19 (via your contract) on Debian, both 
> x86_64.

In case it matters, we use GNAT Pro 19.0w (20180709-73) on x86_64 Red 
Hat 7.4.

> > I tried recompiling ada_mode_wisi_lr1_parse.exe with the following
> > configuration pragmas and found a minor speed improvement but there is
> > indeed an abort statement preventing us from applying pragma
> > No_Abort_Statements. I have a couple of questions about this.
> >
> > First of all, does this affect both parsers?
>
> The abort statement is only used to abort any error recover computation
> tasks that are still running when Recover wants to exit due to an
> unhandled exception.
>
> I'm not clear what you are refering to by "both parsers"; error 
> recovery
> is used by ada_mode_wisi_lr1_parse.exe and 
> ada_mode_wisi_lalr_parse.exe,
> which are the only options for the "process" parser setting of 
> ada-parser.

By "both parsers" I meant ada_mode_wisi_lr1_parse.exe and
ada_mode_wisi_lalr_parse.exe, thanks for the answer.

> No Ada code is used by the "elisp" setting of ada-parser.
>
> > Second, is there a way to redesign the affected parser(s) not
> > to use an abort statement?  If so, the pragma would buy us
> > an immediate 10% performance boost.
>
> Since this is very well debugged, there should be no unhandled
> exceptions, and that abort statement can be removed (at the risk of a
> silent hang in an error recovery that encounters a new situation);
> delete the call to Cleanup in the Recover top level exception handler
> (line 626), and the body of Cleanup (lines 200 .. 207).
>
> Or maybe change the "if" statment in Cleanup to output a warning to
> Standard_Error instead of "abort". That would be visible when running
> run_ada_lr1_parse.exe outside of Emacs, so we'd have some chance of
> diagnosing the problem.

I would prefer that: we'd get both the performance and the diagnoses.

> I could use preprocessor statements to put it back for development, or
> just comment it in/out.

I think unconditional error messages to Standard_Error would be best.

> > Here are the configuration pragmas I applied; they come from
> > lengthy research to optimize the performance of our main
> > application:
[...]
> Which .gpr file do these go in? I'm not used to using configuration
> pragmas. Reading the gprbuild manual, I think I add a
> Builder.Global_Configuration_Pragmas attribute in
> ada_mode_wisi_parse.gpr?
[...]

The configuration pragmas go into a separate file which is referenced
in the .gpr file.  Here is my current patch:

--- ada_mode_wisi_parse.gpr.gp  2018-12-07 17:23:15.756991576 +0100
+++ ada_mode_wisi_parse.gpr.gp  2018-12-17 16:30:14.001696000 +0100
@@ -118,6 +118,9 @@

       --  We use ".exe" extension even on non-Windows, to simplify the 
makefiles.
       for Executable_Suffix use ".exe";
+
+      for Global_Configuration_Pragmas use "configuration_pragmas.ada";
+
    end Builder;

    package Binder is
--- /dev/null
+++ configuration_pragmas.ada
@@ -0,0 +0,6 @@
+pragma No_Heap_Finalization;
+pragma Restrictions (No_Initialize_Scalars);
+-- pragma Restrictions (No_Abort_Statements); -- violated at 
wisitoken-parse-lr-mckenzie_recover.adb:204:16
+pragma Restrictions (Max_Asynchronous_Select_Nesting => 0);
+pragma Restrictions (No_Asynchronous_Control);
+pragma Restrictions (No_Dynamic_Priorities);

--
Ludovic Brenta.