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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,400766bdbcd86f7c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.news.pas.earthlink.net.POSTED!a6202946!not-for-mail From: Jeffrey Carter Organization: jrcarter commercial-at acm [period | full stop] org User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: This can't be done in Ada...or? References: <1108139611.709714.36170@o13g2000cwo.googlegroups.com> <2IcPd.6268$mG6.1474@newsread1.news.pas.earthlink.net> <1108372232.436036.318690@g14g2000cwa.googlegroups.com> <1108456053.837461.20340@f14g2000cwb.googlegroups.com> In-Reply-To: <1108456053.837461.20340@f14g2000cwb.googlegroups.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1bwQd.1171$kU3.57@newsread1.news.pas.earthlink.net> Date: Wed, 16 Feb 2005 00:09:33 GMT NNTP-Posting-Host: 63.186.49.27 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.news.pas.earthlink.net 1108512573 63.186.49.27 (Tue, 15 Feb 2005 16:09:33 PST) NNTP-Posting-Date: Tue, 15 Feb 2005 16:09:33 PST Xref: g2news1.google.com comp.lang.ada:8344 Date: 2005-02-16T00:09:33+00:00 List-Id: Per Lindquist wrote: > Jeffrey Carter wrote: > >> procedure Q is >> package That is new PragmARC.Reflection; > > > Hm, I was so excited about your solution I didn't notice the potential > problem with overhead, but a collegue of mine did: > > One of our target environments is a time-critical real-time system. We > are worried about the execution overhead implied by a package > instantiation (or any 'new' statement) in every subprogram in the > system. > > Will your solution cause overhead for each subprogram call? It will definitely cause overhead, as I see you've discovered. There's a call to Expanded_Name, 2 to Index, and another to Mixed_Case. This component is certainly not suitable for systems with critical timing requirements. There may also be overhead in terms of the amount of storage used. The package declares a number of constant Strings, and I doubt if we can rely on a compiler to discard them (although inside a subprogram, they should go away when the subprogram returns). You can eliminate the call to Mixed_Case, if you don't mind what the result looks like, and one of the calls to Index (it will always return 'Last - 1), and possibly the call to Expanded_Name, if your compilers have 'External_Tag returning the same thing and you're willing to have that compiler dependency in your code (though 'External_Tag probably has similar overhead to Expanded_Name in that case). That still leaves a call to Index. You could eliminate that if you always name your instantiations the same thing and don't mind that extra name on the end. This is really only a problem in subprograms, where the package is elaborated every time the subprogram is called. In packages and other things where the elaboration will only occur once, it may be acceptable overhead. It's too late now, but this might have been a good thing to suggest for Ada 0X. Compilers already have to have this information available, or PragmARC.Reflection wouldn't work. We should be able to get at it without all this overhead. Finally, if you only need the name in exceptional circumstances (error logging or the like), I could make Unit_Name a function. Then you'd only have the overhead when you actually use the name. -- Jeff Carter "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement." Drew Olbrich 51