ada-mode-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephen Leake
Subject: Re: [Ada-mode-users] Performance of ada_mode_wisi_lr1_parse.exe vs. abort statements
Date: Mon, 17 Dec 2018 15:46:55 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt)

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.

> 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.

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 could use preprocessor statements to put it back for development, or
just comment it in/out.

> Here are the configuration pragmas I applied; they come from
> lengthy research to optimize the performance of our main
> application:
>
> 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);

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?

If the same pragmas are not in the wisitoken.gpr file, and I compile
wisitoken separately first, is it recompiled by the ada_mode_wisi_parse
compilation? On the other hand, there's no reason for them not to be in
the wisitoken.gpr file.

-- 
-- Stephe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]