From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:9d57:: with SMTP id g84mr5470412qke.71.1617235390958; Wed, 31 Mar 2021 17:03:10 -0700 (PDT) X-Received: by 2002:a25:6610:: with SMTP id a16mr7579468ybc.339.1617235390757; Wed, 31 Mar 2021 17:03:10 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 31 Mar 2021 17:03:10 -0700 (PDT) In-Reply-To: <8f009bf0-d5a3-42b8-9bd9-12bce24f1093n@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=2601:3c3:401:f550:d016:7221:e4d2:1457; posting-account=JSxOkAoAAADa00TJoz2WZ_46XrZCdXeS NNTP-Posting-Host: 2601:3c3:401:f550:d016:7221:e4d2:1457 References: <07a56dcc-9e17-49b2-a980-3a5a2d265cedn@googlegroups.com> <23dcce3e-0db1-4417-a5d1-a05f03f74464n@googlegroups.com> <302c2e86-2379-46e0-b1f7-d69e7e14f9cfn@googlegroups.com> <86h7kyapsn.fsf@stephe-leake.org> <3b3ff9aa-26b9-4da7-82de-a5f6c1980335n@googlegroups.com> <8f009bf0-d5a3-42b8-9bd9-12bce24f1093n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9233bc10-091c-46af-b613-504bcb5e1c82n@googlegroups.com> Subject: Re: Performance of records with variant parts From: John Perry Injection-Date: Thu, 01 Apr 2021 00:03:10 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:61715 List-Id: On Tuesday, March 30, 2021 at 2:12:36 AM UTC-5, briot.e...@gmail.com wrote: > Since you are on linux, you might want to look at `perf` for performance analysis: > > perf record --call-graph=fp your_program > perf report -g I don't know why I didn't think of that; I've used perf before. It took a while to find the problem (inlining was an issue), but that did the trick! Both variant and non-variant versions now perform at the same speed. The problem was indeed a different location. A function returns an Intersection_Type, which has several fields, one of which was a Thing_Type. So if Thing_Type is variant, Intersection_Type also has to be variant. The non-variant version in Ada was | return ( | if which = 0 then No_Intersection | else ( | thing => things(which), | ray => ray, | dist => dist(which) | ) | ); ...and -gnatD's output for the non-variant version was | return (if which = 0 then objects__no_intersection else ( | thing => things (which), | ray => ray, | dist => dist (which))); The non-variant Ada version was: | return ( | if which = 0 then No_Intersection | else ( | kind => things(which).kind, | thing => things(which), | ray => ray, | dist => dist(which) | ) | ); The -gnatD option (thanks, Simon!) translates this as: | R79b : constant objects__object_type := things (which).kind; | type objects__intersections__A84b is access all | objects__intersection_type; | freeze objects__intersections__A84b [] | R83b : constant objects__intersections__A84b := (if which = 0 | then objects__no_intersection else | do | [subtype objects__intersections__T78b is | objects__intersection_type (R79b)] | A81b : objects__intersections__T78b; | A81b.kind := R79b; | A81b.thing := things (which); | A81b.ray := ray; | A81b.dist := dist (which); | in A81b end | )'reference; | R87b : constant objects__object_type := (R83b.all).kind; | subtype objects__intersections__S86b is | objects__intersection_type (R87b); | return (objects__intersections__S86b!((R83b.all))); That's... wow. Anyone know why all that is necessary? It seems to create a new inline type instead of using the existing type. Studying the code, I realized that there was no reason that Intersections_Type had to keep a copy of thing(which); it could instead just remember which, and the caller could obtain thing(which) directly. That's it. There was nothing else to change. thank you again, very much john perry